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Cisco Certified Internetwork Expert (CCIE) certification is the most difficult and most 
rewarding of the Cisco(r) certifications. Although the professional and financial benefits of a 
CCIE are excellent, attaining this level of certification takes years of experience, study, and 
effort. Serving a dual role of networking reference guide for configuring Cisco routers and 
preparation tool for the CCIE Lab Exams, CCIE Practical Studies, Volume |, is an ideal 
resource to help you achieve and earn the coveted CCIE designation. 


CCIE Practical Studies, Volume 1, provides you with the knowledge to assemble and configure 
all the necessary hardware and software components required to model complex, Cisco- 
driven internetworks based on the OSI reference model-from Layer 1 on up. Each chapter 
focuses on one or more specific technologies or protocols and follows up with a battery of 
CCIE exam-like labs for you to configure that challenges your understanding of the chapter 
topics and measures your aptitude as a CCIE candidate. The final chapter of the book 
provides five CCIE "Simulation Labs." These labs not only test your knowledge but your 
speed as well-a crucial aspect of the new one-day format of the CCIE exam. Among the many 
resources you will need to study for the CCIE exam, you will find CCIE Practical Studies, 
Volume |, to be an indispensable preparation tool. 
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Foreword 


"The will to succeed is useless without the will to prepare" 
—Henry David Thoreau 


The CCIE program is designed to help individuals, companies, industries, and countries 
succeed in an era of increasing network reliance by distinguishing the top echelon of 
internetworking experts. If that sounds like a lofty mission, then our standards for excellence 
are equally high. 


To achieve CCIE certification is to ascend the pinnacle of technical excellence in the IT 
profession. While CCIEs inevitably gain extensive product knowledge on their way to 
certification, product training is not the program objective. Rather, the focus is on identifying 
those experts capable of understanding and navigating the intricacies and potential pitfalls 
inherent in end-to-end networking, regardless of technology or product brand. 


Individuals must first qualify by taking a challenging qualification exam designed to assess 
their knowledge across the complete range of technologies and topologies relevant today. If 
their scores indicate expert level knowledge, candidates then become eligible to take part in 
the CCIE Certification Practical Exam. Administered only by Cisco Systems, this exam truly 
distinguishes the CCIE program from all others. Candidates must demonstrate true mastery 
of internetworking through a series of hands-on, performance-based exercises under intense 
conditions simulating today's mission critical |1T world. 


Becoming a CCIE requires significant investment in education and preparation by each 
candidate. Moreover, a rigorous and mandatory biyearly recertification process ensures the 
commitment is long lasting and helps guarantee program integrity. These rigid requirements 
ensure that CCIEs are leaders with a proven and enduring commitment to their career, the 
industry, and the process of ongoing learning. 


Cisco does not require candidates to complete specific training in preparation for CCIE 
certification because the program is intended to identify hands-on experience and acquired 
expertise rather than the completion of specified course work. 


If you have committed yourself to achieving CCIE certification, CCIE Practical Studies can 
help ensure that your preparation time is invested wisely. An ambitious undertaking given 
the complexity and scope of material covered, CCIE Practical Studies is the first volume in a 
series of books focused on CCIE Practical Exam preparation. The first of its kind, this series is 
written specifically to help individuals practice for the CCIE Certification Practical Exam. 
Although it's no substitute for experience and acquired expertise, CCIE Practical Studies can 
help motivated candidates successfully achieve certification by honing and reinforcing the 
skills and acquired knowledge they already possess. 


Lorne Braddock 
Director, CCIE Programs 
Cisco Systems, Inc. 
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Introduction 


In late 1993, Cisco threw down the certification gauntlet with the introduction of the Cisco 
Certified Internetworking Expert program. Over the years and preceding this, people were 
attaining certifications at an unprecedented rate. From this mountain of newly certified 
people, a new term arose: paper certifications. The term "paper" was used because people 
were passing these tests without ever touching the equipment that they were getting 
certified on. Essentially, their knowledge existed on paper. The certifications that people 
worked so hard to achieve were becoming more common and were meaning less each day. 


The market had enough paper certifications and demanded a new hands-on approach to 
certifications. The industry needed a way not only to measure someone's theoretical 
knowledge, but also to measure a person's hands-on abilities. Cisco developed the CCIE 
program specifically with this in mind. The CCIE certification starts where most certification 
programs end, with an intense, two-hour written test. After successful completion of this test 
—a passing score of 70 is required, the person becomes a CCIE candidate and is eligible to 
take the CCIE practical or the lab portion of the test. The practical exam is an intensive 8 1/2- 
hour test. It is during this period that the candidate demonstrates theoretical knowledge by 
applying it in the lab. 


This text is the first book authorized by Cisco Systems addressing the CCIE practical exam. It 
represents the dedicated work of nine CCIEs, with input from many other CCIEs and authors. 
Our hope is that this text, along with its successors, will shed some light on the CCIE 
practical exam as well as help you prepare for it. 
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Goals 


Our goal in this book is not to instruct you on how to pass the CCIE practical exam, but 
rather to guide the engineer through the process of deploying and modeling different WAN 
and LAN technologies in laboratory environments—in essence, the same principles that the 
CCIE exam is measuring. It is our hope that you will use this book not only for your studies 
but also has a reference in the field. 


When we began crafting this book, we originally wanted to include every topic that we could 
find on the CCIE test. Our first outline had BGP, IPX, AppleTalk, DECnet, and so on, but soon 
we realized that we simply could not cover all the possible topics on the CCIE practical exam 
in a single book. Topics such as BGP require more than a hundred pages to cover properly at 
the CCIE level. We did not want to include these topics just for the sake of having them. 
Therefore, we have already begun work on CCIE Practical Studies, Volume II. This book will 
cover many of the topics that we simply could not fit into the first volume. These topics 
include BGP, IPX, multicast, and VPN, among others. 
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Who Should Read This Book? 


This book can be used as a general networking reference guide for configuring Cisco routers. 
It primarily is designed to help the CCIE candidate prepare for the CCIE practical exam by 
offering many labs for the candidate to work through. The labs are presented in a way that 
actually tests the candidate's ability to solve and work on the lab, before seeing the answers. 
We strongly advise working through the labs because many things have been designed into 
the labs that can make them very difficult to configure. If you don't actually configure the 
labs, you might miss some of these "small" things that could make a difference on your 
actual CCIE exam. 


This book is targeted toward network engineers who already have at least a CCNA or CCDA 
certification. The engineer must have a solid understanding of IP addressing and subnetting 
before reading this book. A good background on Cisco routers and basic configuration 
experience on routers also will be helpful during your reading. 
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How This Book Is Organized 


This book's organization follows that of the OSI model and how networks are built in general, 
from Layer 1 on up. The first chapter deals mostly with the physical layer and basic router 
setup and access. Part |V, "Routing Protocols," focuses on Layers 3 and 4. Each chapter is 
followed by one or more complex labs. The labs are designed to be worked through before 
viewing the walkthrough for the lab. 


The major parts of the book cover the following topics: 


e Partl, "Modeling the I nternetwork"— This part addresses basic and advanced 


router setup, including the 16-bit boot register, password recovery on routers and 
switches, analog access, and the configuration of an access server. This part also 
includes modeling the internetwork, which covers Frame Relay switching, and the 
types of cables and other network equipemnt needed to model complex networks. 


e Part Il, "Modeling LANs"— This part includes detailed information on configuring 
the Catalyst Ethernet and Token Ring series of switches. It includes information on 
configuring the Ethernet Catalyst 2900/3500 and 4000/5000/6000 families of 
switches and the Token Ring 3920 switch. Detailed information on VLANs, VTP and 
trunking protcols, and Spanning Tree also is covered. 


e Part Ill, "Connecting LANs with Wide-Area Networks (WANs) "— This chapters 
covers the configuration of data link protocols used on the WAN. This includes detailed 
configuration information on HDLC, PPP, Frame Relay, Voice over X, ISDN, and ATM. 


e PartIV, "Routing Protocols"— This part focues on the primary interior routing 
protocols and their configuration. Information is provided on RIP and RIP v2, IGRP, 
OSPF, and EIGRP. 


e Part V, "Transporting Non-Routable Protocols"— This part consists of a large 
single chapter. The chapter addresses configuring transparent bridging, integrated 
routing and bridging, source-route bridging, remote source-route bridging, and Data 
Link Switching Plus. 


e Part VI, "Controlling Networks and Network Access"— This part of the book 


deals exclusively with the various ways to configure and apply an IP access lists. 
These include configuring standard and extended access lists, named access lists, and 
dynamic access lists. Binary math and wildcard masks also are addressed in detail. 


e Part VII, "Enhanced Network Protocols"— This part is divided into three chapters 


that cover some of the more common feature sets available on Cisco routers. These 
features include NAT, HSRP, and NTP/SNTP. This part addressses the details of 
configuring each feature set. 


e Part VIII, "CCIE Prepartion and Self-Assessment" — This part discusses the 


current CCIE practical exam. It provides study lists and suggestions to help you 
prepare for the CCIE Lab Exam. The chapter also includes five CCIE practice exams. 
The exams are provided to give the candidate a "feel" for what the real exam is like. 
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Command Syntax Conventions 


The conventions used to present command syntax in this book are the same conventions 
used in the Cisco |OS Command Reference. The Command Reference describes these 
conventions as follows: 


Vertical bars (|) separate alternative, mutually exclusive elements. 

Square brackets [ ] indicate optional elements. 

Braces { } indicate a required choice. 

Braces within brackets [{ }] indicate a required choice within an optional element. 
Boldface indicates commands and keywords that are entered literally as shown. In 
actual configuration examples and output (not general command syntax), boldface 
indicates commands that are manually input by the user (Such as a Show command). 
e Italics indicate arguments for which you supply actual values. 
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Part I: Modeling the Internetwork 


Chapter 1 The Key Components for Modeling an Internetwork 


Part | Modeling the Internetwork 
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Chapter 1. The Key Components for Modeling an 
Internetwork 


Many types of models exist today, from mathematical models and statistical models to the 
plastic models that you might have built when you were young. Despite their vast 
differences, they all are models of one type. This book proposes a new kind of model—the 
internetwork model. 


The internetwork model will be defined as a smaller accurate and functional representation of 
a larger internetwork. Internetwork models, as with all models, are smaller representations of 
larger networks. The word accurate is used because the model will be built to reflect the 
precise requirements of "real" networks. For example, not only will you design an Open 
Shortest Path First (OSPF) network, but you also will focus on the details of the design, such 
as OSPF handling of specific interface types, what areas they are in, and whether they should 
be transmitting link states or forming adjacencies. Attention to this type of detail will be 
important in your studies and thereby warrants the use of the word accurate. Finally, the 
model must be functional—that is, it will be tested by running actual data and applications 
across it. 


Just as other models serve a purpose to prove a hypothesis of one sort, the goal of the 
internetwork model will be to prove the functionality or design theory of the larger 
internetwork. When you are finished, you will be able to transport many kinds of data across 
many types of networks. You will see and test the functionality of the network by using test 
hosts and simulated data. 


In summary, an internetwork model is a smaller but accurate representation of the larger 
internetwork. The goal of this book is to walk the network engineer through assembling and 
configuring all the necessary hardware and software components required to model complex 
internetworks. 


The term internetwork can be defined as a collection of networks, local-area networks (LANs) 
and wide-area networks (WANs) interconnected by routers, bridges, and switches that 
function as a singular network. To properly model an internetwork in the lab, you need to 
simulate different LAN and WAN technologies. 


You should go through a logical order when modeling the internetwork. Like mathematics, 
networking builds on itself. You must first comprehend multiplication and division before you 
can learn algebra, you must learn algebra before calculus, and so on. Networking follows a 
similar logical approach: 


Step 1. First, build and form all LAN connections. 


Step 2. After initial LAN connectivity is established, build and configure all WAN 
connections. 


Step 3. Establish full internetwork connectivity. This is done by laying routing 
protocols over yosur LANs and WANs. 


Step 4. Finally, apply any filters, features, or any other exterior routing protocols, 
such as Border Gateway Protocol (BGP), that require a fully functional |P network to 
operate. 
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Identifying the Key Components Needed for Modeling 
Internetworks 


You need several key components to fully model complex network designs, including the 
following: 


e Access server 
e LANs: switches/hubs and cables 


e WANs: routers and cables 


e Routers 
e Test hosts and applications, preferably Microsoft Windows 95/98/2000 or Windows NT 


The preceding list should be viewed more as a list of roles than a list of devices. The specific 
device type is not relevant; what is relevant is the role that the device plays in the model. 
There are many ways to simulate a WAN. For example, some network models are more 
accurate if a Frame Relay switch is deployed in the model, while some models might require 
only a WAN connection because the protocol needed is irrelevant. 


The only component in this list that could be considered optional is the access server. The 
role of the access server can be a useful one, both in the laboratory environment and in the 
field. In the field, the access server provides out-of-band management where groups of 
routers are located. Instead of using multiple modems for dial-in access to routers, an access 
server can serve as a central point for out-of-band management, requiring only one modem 
instead of many. The primary role of the access server in the lab will be to provide simple 
and quick configuration access to a stack of routers. We will go over each one of these 
components in detail and further discuss their relevance in the lab. 
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The Access Server 


You use the access server as the primary configuration device. From this device, you 
configure the other routers and switches through a reverse Telnet session. The Cisco routers 
that accomplish this function the most efficiently are the Cisco routers with the SCSI-I| 68- 
pin async port and the eight-to-one octopus cable. The most common routers that provide 
this port are the following: 


e Cisco 2509/2510 
e Cisco 2511/2512 
e Cisco 2600/3600 with SCSI-II 68-pin 16/32-port async port 


Any Cisco router might be configured for asynchronous communications on its serial ports. A 
Cisco router with multiple serial ports, such as a Cisco 2522, can also be used as an access 
server. Regardless of whether you use a router like the 2509 with its SCSI-I!] 68-pin port or a 
Cisco 2522 with its 10 serial ports, you need require special cables and a unique 
configuration. 


The most common routers that serve the function of an access server are the Cisco 
2509/2510 and the Cisco 2511/2512 routers. The Cisco 2509 has one Ethernet port and eight 
asynchronous ports, whereas the Cisco 2510 has one Token Ring port and eight 
asynchronous ports. The eight asynchronous ports utilize a Cisco eight-to-one cable, referred 
to as the octal cable. The part number is CAB-OCTAL-KIT, which also includes modem head- 
shells for any asynchronous devices, such as modems. The R]-45 end, of one of the eight 
cables, plugs into the console port of each router in the lab. You use what Cisco calls reverse 
Telnet to configure the routers through this cable. This should be called internal Telnet—there 
is nothing reverse about the way Telnet is used to configure the routers. Actually, Telnet is 
used as the protocol to communicate with a device through a specific internal port or line 
number. 


NOTE 


For a complete list of the pinouts of these cables, head-shells, and any other 
cables mentioned in this book, see Appendix D, "Common Cable Types and 
Pinouts." 


The 2511 access server uses a 68-pin connector and breakout cable, which provides 8 RJ-45 
ports on each cable. These ports can also use RJ -45-to-DB-25 adapters to connect to 
asynchronous devices. The Cisco 2511/2512 is modeled in the same format but supplies an 
additional eight asynchronous ports. 


Figure 1-1 illustrates the back of a Cisco 2511 router and the eight-to one cable. 


Figure 1-1. Cisco 2511 Router and the Eight-to-One Octopus Cable 
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The other form of access server is using serial ports on a router such as a Cisco 3600 series 
with an eight- port serial module or the Cisco 2522 series with ten serial ports. You can to 
connect serial cables to various head shells to run asynchronous communications in 
numerous ways. Essentially, the best combinations require a RS-232 serial cable, either DTE 
or DCE, an RJ -45-to-DB-25 adapter, and a rolled or straight-through cable. For the precise 
pinouts of the RS-232 serial cables and the rolled cable, see Appendix D. The RJ -45-to- DB- 
25 adapter has three flavors: a DTE M/F, DCE M/F, and MMOD. The female DTE head- shell 
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from Cisco has the label Terminal on one side. The MMOD head-shell (the most common) has 
the label MODEM on it. This is the same head-shell used on Cisco 4000 and 7000 series 
routers for the console port, and it is the same head-shell used to connect the terminal 
server to a modem. 


Two common and inexpensive cabling options involve using RS-232 cables as a terminal 
server cables: 


e Cable method 1— Use a Cisco female RS-232-to-DB-60 serial cable, the RJ -45-to- 
DB-25 head-shell labeled MODEM, and a Cisco rolled cable. Connect the cables in the 
logical fashion; then, from the configuration mode, under the interface mode, enter 
the physical-layer async command. This forces asynchronous communications out 
the serial port. In the next section, you learn how to completely use this command 
along with the transport input command to configure reverse Telnet sessions to 
your router's console ports. 


e Cable method 2— This method is similar to cable method 1, but you use different 
cables and head-shells. This method requires a Cisco male RS-232-to-DB-60 serial 
cable, the RJ-45-to-DB-25 head-shell labeled TERMINAL, and a Cisco rolled cable. 
Again connect the cables in the logical fashion, and add the physical-layer async 
command under the serial interface. 


NOTE 


The serial port must be a synchronous/ asynchronous port to use these cable 
methods. For example, the ports on a Cisco 2501 are synchronous only, so 
these cable methods will not work. 


Table 1-1 shows all the pinouts for the RJ -45-to-DB-25 adapters, while Table 1-2 shows 
asynchronous device cabling options. 


Table 1-1. Pinouts for the RJ -45- to- DB-25 Adapters 


Adapter RJ -45 DTE M/ F Pins DCE M/ F MMOD Pins 
TERMI NAL Pins —— 
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Table 1-2. Asynchronous Device Cabling Options 


Access Server RJ -45 Console Head- Shell End 
Port Cable Type Adapter Device 


Console or aux Rolled DTE pinout 


Console or aux Straignt pce pinout 


‘Console or aux [Rolled IMMOD/MODEM 


The access server can perform multiple roles. Not only can you use this device for easy 
configuration of the other routers in your stack, but the other serial and LAN ports can be 
used independently of the terminal server functions. For example, the terminal server could 
be configured as a route generator or a backbone router. The access server can also be used 
for remote configuration of the lab through analog dialup. Both of these topics are discussed 
in detail later in this chapter. The access server is discussed in the section "Configuring 


Analog Remote Access." 
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Modeling Local-Area Networks (LANs) 


A major part of modeling the internetwork consists of modeling LANs. Each lab in this book 
has a special section entitled "Equipment Needed," This section lists the minimum hardware 
requirements needed to complete that particular lab. Some labs might require only a 
crossover cable or two to connect two routers. Other labs might require a host connection, so 
you need to use either a hub or a switch when modeling your LANs. Four ways exist in which 
to model and simulate LANs: 


Modeling LANs by using hubs and media attachment units (MAUs) 
Modeling LANs by using switches 

Simulating LANs by using route generators or backbone routers 
Modeling a LAN with an Ethernet crossover cable 


Modeling Versus Simulating 


We use the terms modeling and simulating to describe the character of 
the network. When the term model is used, it means that the network can 
be used to transport data, and it represents a smaller version of the larger 
network. When the term simulated is used, it implies that the network has 
only one host and that no data can be sent across the network. The 
network must be capable of being advertised by a routing protocol to be 
simulated. An example of a simulated network is a loopback interface or 
an Ethernet interface with the keepalive removed. 


Modeling LANs by Using Hubs and MAUs 


In a controlled environment, it is necessary to model Layer 1 technologies. The two LAN 
technologies that we are focusing on are Ethernet and Token Ring. The easiest way to model 
Layer 1 is by the use of hubs and MAUs. Most of the labs in this book require multiple hubs of 
multiple types. Physically, the number of network segments are limited by the number of 
Ethernet or Token Ring interfaces present on the routers in the lab. The type of hubs that you 
use is not significant; what's important is that the hub is fully operational and has two or 
more ports. Some hubs are manageable and send IPX SAPs, which can be a useful feature for 
testing |PX filtering. Other times, it is preferable to have a nice, quiet MAU running in the lab. 
MAUs generate less heat, no electricity, and no noise. What type you chose to use in your 
model is up to you. 


Modeling LANs by Using Switches 


The cleanest way to simulate many LANs is with the use of switches. One switch can be 
configured to accommodate many virtual LANs (VLANs). A good way to think of a VLAN is as 
a standalone hub. So, instead of having many hubs to accommodate the routers, you need 
only one switch with a few VLANs. Chapter 2, "LAN Protocols: Configuring Catalyst Ethernet 


and Token Ring Switches," provides a detailed explanation of VLANs and a switching 


overview. Using switches to model your LANs also saves on rack space and power 
requirements, although they are more expensive than hubs. 
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Simulating LANs by Using Route Generators or Backbone Routers 


Two other quick ways to simulate LANs are by using a loopback interfaces and using a no 
keepalive command on the router's Ethernet interface. These two methods can be useful in 
creating a route generator or backbone router. A route generator is a device connected to a 
test network for the purpose of sending and receiving routing updates. A router configured 
with many loopback addresses with routing protocols will appear as an entire network of 
routers to a downstream neighbor. We use this functionality in the lab to help simulate 
networks for route filters and route maps. 


Examples 1-1 and 1-2 use a Cisco 2501 as a route generator. Notice that no keepalive has 
been added to the Ethernet to spoof it as up. Also note that the default keepalive value of 10 
seconds is now replaced with not set. When you disable the keepalives on the Ethernet 
segment, you will notice that packets output, output errors, and lost carrier counts all 
increment together. Do not forget to add a keepalive when you reconnect your Ethernet port 
back to a real hub or switch. The default value of 10 will automatically be set. 


Example 1-1 Configuring a Two-Route Generator; Simple Loopback 
Address 


Router#con£t t 

Enter configuration commands, one per line. End with CNTL/Z. 

Router (config) #int loopback 20 

Router (config-if) # 

SLINEPROTO-5-UPDOWN: Line protocol on Interface Loopback20, changed state to up 
Router (config-if)#ip address 172.16.16.1 255.255.255.0 

Router (config-if) #exit 

Router (config) #int loopback 21 

SLINEPROTO-5-UPDOWN: Line protocol on Interface Loopback21, changed state to up 
Router (config-if)#ip address 172.16.17.1 255.255.255.0 

Router (config-if) #exit 

Router (config) #router eigrp 2001 

Router (config-router) #network 172.16.0.0 

Router (config-router) #*Z 

Router# 


Example 1-2 Configuring a Route Generator; Spoofing Ethernet 


Router#con£t t 
Enter configuration commands, one per line. End with CNTL/Z. 
Router (config) #int ethernet 0 
Router (config-if)#no keepalive 
Router (config-if) #*Z 
Router# 
Router#show int e0 
EthernetO is up, line protocol is up 
Hardware is Lance, address is 0000.0c8d.54ac (bia 0000.0c8d.54ac) 
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 235/255, load 1/255 
Encapsulation ARPA, loopback not set, keepalive not set 
ARP type: ARPA, ARP Timeout 04:00:00 
Last input never, output 00:00:18, output hang never 
Last clearing of "show interface" counters never 
Queueing strategy: fifo 
Output queue 0/40, O drops; input queue 0/75, O drops 
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5 minute input rate 0 bits/sec, 0 packets/sec 
5 minute output rate 0 bits/sec, 0 packets/sec 
0 packets input, O bytes, O no buffer 
Received 0 broadcasts, O runts, O giants, 0 throttles 
QO input errors, O CRC, O frame, O overrun, O ignored, O abort 
O input packets with dribble condition detected 
21 packets output, 3030 bytes, O underruns 
21 output errors, O collisions, 2 interface resets 
0 babbles, O late collision, 0 deferred 
21 lost carrier, O no carrier 
O output buffer failures, O output buffers swapped out 
Router# 


Modeling LANs by Using an Ethernet Crossover Cable 


A commonly known way to connect two Ethernet hosts is to use an Ethernet crossover cable. 
An Ethernet crossover cable is simply an RJ-45-to-RJ-45 patch cable, pinned out in a 
crossover pattern. The obvious limitation is that the crossover cable can be used to connect 
only two devices. In the lab environment, you can use this cable to connect two routers or to 
connect a router to one host. Figure 1-2 shows the pinouts for Ethernet crossover cable. 


Figure 1-2. Pinouts for an Ethernet Crossover Cable 
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Simulating Wide-Area Network Connections 


The other major part of modeling the internetwork consists of WAN connections. At this point 
in the design, you are concerned only with |1SO Layer 1. You will continue to model the 
internetwork from Layer 1 on up because this is the most logical way to build any network. 
First, you will build all the physical connections to all your devices, and then you will 
configure all LAN interfaces, WAN interfaces, and finally your different networks together with 
routing protocols. Constructing a network in a layered approach allows for future growth and 
adaptation by upgrading or replacing a single layer at a time, while leaving the remaining 
layers unchanged. With this in mind, we will focus on physical aspects, such as cable types 
and pinouts. Part III, "Connecting LANs with Wide Area Networks (WANs)," focuses on |1SO 


Layer 2 protocols. 


You can model WAN connections in three primary ways, and you can simulate a WAN in one 
way in a Cisco environment: 


e You can model WANs by using a special crossover cable for routers with WAN 
Interface Cards (WICs) or external CSU/DSUs. 

e You can model WANs by using V.35 DTE cable to a V.35 DCE cable, or any serial cable 
in a DTE-to-DCE configuration. 

e You can simulate WANs by using loopback plugs on CSU/DSUs. 

e You can model WANSs by using a Cisco router as a Frame Relay or X.25 switch. 


NOTE 


Of course, no book on networking would be complete without mentioning the 
OSI model; Appendix B, "The 'Abridged' OSI Reference Model," presents a brief 
overview of the OSI model. 


Modeling WANs by Using Special Crossover Cable Routers with Built-In or 
External CSU/DSUs 


Two routers with built-in or external CSU/DSUs can be connected in a "back-to-back" mode. 
This functions as the Layer 1 for many WAN protocols, including PPP, HDLC, and others. This 
is done by utilizing a special crossover cable made from pinning out specific pins of a four- 
pair Category 5 cable. It is important to note that the crossover cable needed differs slightly 
from a T1 to a 56-kbps DSU. You must connect a router with a Tl service unit or CSU/DSU to 
another router with a T1 service unit or CSU/DSU. The same is true for a 56-kbps service 
unit. Figures 1-3 and 1-4 illustrate what pinouts you need to make a crossover cable, from a 
Category 5 cable for a T1 CSU/DSU and a 56-kbps CSU/DSU. 


Figure 1-3. Pinouts for a Crossover Cable for T1 Service Module or 
CSU/ DSU 
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Figure 1-4. Pinouts for a Crossover Cable for 56-kbps Service Module 
or CSU/ DSU 
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Modeling WANs by Using a V.35 DTE Cable to a V.35 DCE Cable 


The most common way to provide Layer 1 connectivity between routers is to connect a 
female V.35 DCE cable to a male V.35 DTE cable. The key factor in any back-to-back 
configuration is ensuring that one side of the link sets clocking. This is always the DCE side of 
the link. To configure the clock rate for an interface, simply add the command clock rate 
[value]. Example 1-3 demonstrates how to set the clocking on a serial interface to 64,000 
bps. 


Example 1-3 Configuring the Clockrate on a DCE Interface 


frame_relay_switch(config) #int serial 5 
frame_relay_switch(config-if) #clockrate 64000 
frame_relay_switch(config-if) #*2Z 
frame_relay_switch# 


It is important to ensure that the cable is truly a V.35 DTE cable connecting to a V.35 DCE 
cable. The sex of the DCE or DTE cable is not relevant; however, you must connect a DCE 
side to a DTE side, and set the clock rate, as demonstrated in Example 1-3. Figure 1-5 
illustrates many of the standard Cisco cable connectors, ranging from the common vee 


RS-232 interfaces to ElLA613-HSSI interfaces. 


Figure 1-5. Common Cable Interfaces for Cisco Routers 
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These cables can be ordered from Cisco Systems, part number CAB-V35MT for the V.35 male 
DTE cable, and CAB-V35FC for the female DCE cable. Several companies also make serial and 
crossover cables at reasonable prices. 


At times when the cables are connected in a back-to-back mode, it might be hard to tell 
which one is the DCE cable. You might be in the field or working remotely, and you might not 
have physical access to your lab—how, then, can you tell which cable is the DCE cable? The 
show controller command shows the cable type and shows whether the cable is DCE or 
DTE. Example 1-4 shows two interfaces on a Cisco 2501 router. Using the show controller 
command, you can tell what the interface type is. 


Example 1-4 Example of the show controllers Command 


Router#show controller serial 0 
HD unit 0, idb = OxCED94, driver structure at 0xD3B18 


cpb = O0xE2, eda = 0x4140, cda = 0x4000 

RX ring with 16 entries at 0xE24000 

00 bd_ptr=0x4000 pak=0x0D66F0O ds=0xE2DDBO status=80 pak_size=0 
**e* text. omitted*** 


Router#show controller serial 1 
HD unit 1, idb = 0xD7788, driver structure at 0xDC508 


cpb = O0OxE3, eda = 0x2140, cda = 0x2000 

RX ring with 16 entries at 0xE32000 

00 bd_ptr=0x2000 pak=0x0DFOE4 ds=0xE3C468 status=00 pak_size=0 
**A*C SOX Omibted*** 


Interface Serial 0 is a V.35 DTE cable, and interface Serial 1 is an RS-232 DCE cable. Other 
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serial cables, such as RS-232, are used for back-to-back connections, as long as a DCE cable 
is connected to DTE cable. It is important to note that each different cable type has certain 
speed restrictions. For example, it is not possible to simulate Tl speeds on RS-232 cables. 
For the most flexibility in lab environments, use V.35 cables whenever possible. 


Sometimes, you might want to switch your lab environment rather rapidly. You might want a 
serial connection attached to one router one day, whereas the next day you might want that 
same connection to go to another router. In these situations, it is best to use a patch panel of 
some sort. A V.35 patch panel is a common sight at large labs. The V.35 patch panel is 
simple to work with. Most V.35 patch panels have a female DTE port located on top, in the 
rear, and a V.35 male DCE port located in the middle, in the rear. The routers plug into these 
ports, the DTE cable to the DTE port, and the DCE cable to the DCE port. On the front of the 
patch panel are small patch ports, with one port in front of each DTE and DCE port. A black 
patch cable then enables you to patch one DTE port to one DCE port, thereby connecting one 
router to another router. 


To change the configuration, simply move the patch cable to another patch port. Using a 
patch panel in this manner allows for quick and rapid physical configuration of many serial 
links. Patch panels should be labeled on the front to designate which is the DCE and DTE port 
—this can be key when troubleshooting physical layer issues. Figure 1-6 illustrates a V.35 


Patch panel. 


Figure 1-6. V.35 Patch Panels 
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Most patch panels also have a bottom port, right below the DCE port. This port is used for 
attaching a line monitor or data scope. 


Simulating WANs by Using HDLC and Loopback Plugs on CSU/DSUs 


Yet another way to use WAN interfaces in your model is to deploy loopback plugs on your 
CSU/DSUs combined with running HDLC protocol. In addition, by putting a Layer 3 address, 
such as an IP or IPX address, on the interface, the interface will respond to pings and will 
show up in routing tables. The Layer 2 encapsulation must also be set to HDLC when using 
loopback plugs. Routers with built-in CSU/DSUs or WAN interface cards (WICs), and even on 
routers with external CSU/DSUs, can have a loopback plug installed into the RJ-45 jack, thus 
spoofing the WAN interface as up. Example 1-5 illustrates output from the show interface 
command on a Cisco 2524, with a T1 WIC and a loopback plug installed. 


42 


Example 1-5 The show interface Command of a Cisco 2524 with a T1 
Loopback Plug Installed in Its WIC 


router# show interfaces serial 1 
Seriall is up, line protocol is up (looped) 
Hardware is HD64570 with FT1 CSU/DSU 
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255 
Encapsulation HDLC, loopback not set, keepalive set (10 sec) 
Last input 00:00:02, output 00:00:02, output hang never 
Last clearing of "show interface" counters never 
Input queue: 0/75/0 (size/max/drops); Total output drops: 0 
Queueing strategy: weighted fair 
Output queue: 0/1000/64/0 (size/max total/threshold/drops) 
Conversations 0/1/256 (active/max active/max total) 
Reserved Conversations 0/0 (allocated/max allocated) 
5 minute input rate 0 bits/sec, 0 packets/sec 
5 minute output rate 0 bits/sec, 0 packets/sec 
2537 packets input, 148733 bytes, 0 no buffer 
Received 2537 broadcasts, O runts, O giants, O throttles 
O input errors, O CRC, O frame, O overrun, O ignored, O abort 
2537 packets output, 148733 bytes, O underruns 
O output errors, O collisions, 1 interface resets 
0 output buffer failures, O output buffers swapped out 
1 carrier transitions 
DCD=up DSR=up DTR=up RTS=up CtTS=up 
router# 


NOTE 


Loopback plugs can be useful in the field. Whenever a CSU/DSU or WIC is 
suspected to be malfunctioning, installing a loopback plug can quickly test the 
physical layer to the CSU/DSU. When the loopback plug is installed, the show 
interface command should show the interface as line up, protocol up and 
(looped). 


A loopback plug can be easy to make. You can use a simple cable kit to construct these 
plugs, or you can order them from most cable vendors, if they are supplied with the diagrams 
in Figures 1-7 and 1-8. Figure 1-7 demonstrates the pinouts required for an RJ-45 56-kbps 
loopback plug, while Figure 1-8 illustrates the pinouts required for an RJ-45 Tl or 1.544- 
Mbps loopback plug. 


Figure 1-7. Pinouts for an RJ -45 56-kbps Loopback Plug 
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Figure 1-8. Pinouts for an RJ-45 T1 Loopback Plug 
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Modeling WANs by Using a Cisco Router as a Frame Relay or X.25 Switch 


The third way to model a WAN is to configure a Cisco router as a Frame Relay or an X.25 
switch. Any Cisco router with Cisco |OS Software Release 11.0 or later and at least two serial 
interfaces can be configured as an actual Frame Relay or X.25 switch. When configured as a 
Frame Relay switch, the router actually sends and receives the Frame Relay Local 
Management Interface (LMI), and it can even be configured to use Network-to-Network 
Interface (NNI), the standard interface between Frame Relay switches. Two interfaces are 
always needed because the switch is primarily a DCE device and requires two routers to 
serve as the DTE devices. Because the Frame Relay switch is a DCE-only device, it requires 
DCE serial cables as well. 


The Cisco 2522 and the 2523 series routers can perform the function of a Frame Relay switch 
with ample ports for many end devices. The Cisco 2522 provides two high-speed synchronous 
serial ports and eight low-speed asynchronous/synchronous serial ports. This router also has 
one Ethernet port in an RJ-45 or AUI configuration, and one ISDN BRI U interface in an RJ-45 
configuration. The Cisco 2523 is exactly the same as the 2522, but instead of the Ethernet 
port, it has an RJ-45 Token Ring interface. Any Cisco router with multiple serial interfaces is a 
good choice for a Frame Relay or X.25 switch. The Frame Relay switching functions run 
independently of normal router functions, such as IP routing. Thus, this router can be used 
not only as a Frame Relay switch, but also as another routed device or a route generator. The 
detailed software configuration of a Frame Relay switch is covered later in this chapter, in the 
section "Configuring a Frame Relay Switch." 


TIP 


During the course of your studies and career in networking, you will come across 
many terms and acronyms. Sometimes, it can become difficult to remember all 
the rules, such as a DCE side requires a clock. One method of memorization that 
| use is word association. For example, | know that there are DCE and DTE sides 
to a cable. The C is the difference between the two, and C stands for "clock." 
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Thus, the DCE side is the side on which you configure the clock signal. 


At this point, you might be wondering, "What about ATM? That's a LAN and WAN protocol— 
where does that fit in?" Asynchronous Transfer Mode (ATM) was originally called the "duck" 
of networking because it was like a duck in a metaphorical sense. A duck can swim, fly, and 
walk. It doesn't walk that well and swims okay, but it flies really fast. ATM can do voice, data, 
and video, although it does some of them better then others. | had the same classification 
problems in deciding where to talk about ATM. Because ATM is a LAN and WAN technology 
and is highly specialized, it is covered in Chapter 8, "WAN Protocols and Technologies: 
Asynchronous Transfer Mode (ATM)." 
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Routers, Cisco IOS Software, and Memory Requirements for Labs 


Throughout this book, every lab has different hardware and software requirements. As 
mentioned earlier, preceding each lab is a section entitled "Equipment Needed." This section 
lists the minimum amount of equipment needed to complete that lab. Some labs are rather 
easy and might require only two or three routers with IP routing software. Other labs, such 
as those for configuring SNA, are rather complex and require the enterprise feature set and 
multiple routers. Finding routers, hubs, and such can be difficult. 


Unfortunately, it is hard for some companies to realize the benefit of the age-old saying 
"Practice makes perfect." Companies can have a hard time finding enough room in the 
budget for labs so that their engineers can finely hone their skills. 


Personally understanding the difficulty in attaining networking equipment, | have tried to 
involve the fewest amounts of routers/hubs as possible in these labs. I've also made the 
studies independent of one another, so if you don't have access to a Token Ring/Ethernet 
router or a switch, you can still perform a majority of the labs. For example, to perform the 
translational bridging lab, you need a Token Ring interface and an Ethernet interface on the 
same physical router. Because many Cisco routers can accommodate multiple LAN segments 
of different types, | won't go into details on specific router models. A good rule to follow 
when investing in new routers is, the more modular the router is, the more flexibility you 
have in creating multiple models. Investing in modular routers also protects your investment 
because most routers can be upgraded with the installation of new networking modules. 


NOTE 


The Comdisco lab uses primarily Cisco Catalyst 5500s, Cisco 2500s, 4500s, and 
3600 series routers for modeling network scenarios. The Cisco 3600 series 
router can accommodate almost any networking requirement; this includes ATM, 
Gigabyte Ethernet, Voice over IP or Frame Relay, along with VPN technology. 


When all the hardware is gathered, you are ready to begin discussing the Cisco Internetwork 
Operating System (10S) Software releases, DRAM memory, and FLASH memory 
requirements that the models require. All three are tightly related to each other. The 
protocols and Cisco feature sets that you use drive the amount of DRAM memory needed to 
execute that feature. The Cisco |OS feature set is stored in FLASH memory. Therefore, the 
more features and protocols that are in use, the more DRAM and FLASH memory will be 
required. The labs listed in this book utilize most of the major routing protocols and most 
major feature sets. To easily accommodate this, the Enterprise Plus feature set could be 
installed on all the routers. The Cisco |OS Software release level should be at least 11.2.x or 
12.0.x. If you are specifically practicing for the CCIE Lab Exam, use a minimum IOS level of 
12.0 on all routers. If the lab requires an |OS feature greater than IP routing, it will be noted 
as a requirement. 


NOTE 


To find the exact minimum memory requirements for the specific Cisco 10S 
Software and feature set in use, consult Cisco's Web page, www.cisco.com. 
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Test Hosts and Data Simulation 


The ultimate goal of all networks is to transport data from one place to another. Without data 
to transport, there would be no need for networks. To ensure that any model is working 
properly, test data is always required. Networking has no exception to this rule. Without test 
data of some sort, it would be difficult to test many networking features. Features such as 
remote source-route bridging (RSRB) actually need to send and receive data before the RSRB 
becomes active. A data-link switching (DLSw) peer can be connected, but no circuit becomes 
active until data is sent. Therefore, to properly test the models, you need to simulate data of 
many kinds. Your challenge will be testing complex protocols, such as SNA, without installing 
a mini-mainframe in your labs. 


Fortunately, the Microsoft Windows 95/98/2000-based operating systems ship with three 
Major protocols that help in testing your networks. Microsoft Windows 95, 98, and 2000 all 
ship with TCP/IP, |PX/SPX, and NetBEUI as installable protocols. These three protocols allow 
numerous testing of many Cisco |OS Software features. 


For example, two Windows-based workstations running NetBEUI can be used to test DLSw 
peers across an internetwork. Browsing Network Neighborhood will force an all-routes 
explorer frame to be generated. The name that you entered in the Control Panel/ Network/ 
Identification Name dialog box will be the name that appears during the show disw 
reachability command. As another example, in an RSRB environment, this explorer frame 
would be enough to bring up the remote source bridge and force a connection to the other 
remote source bridge. 


Installing TCP/IP allows you to use many shareware utilities, such as FTP, TFTP, and DHCP, 
for testing. By actually setting up end stations, filters will take a more true-to-life form when 
you can actually see them at work. All these IP-based utilities are shareware that you should 
be able to find online. 


NOTE 


| installed my first home network in 1993, on the same day that the computer 
game DOOM was released. DOOM allowed for 3D multiplayer computer games 
over a network through IPX. We pooled our money, and hours later, we were 
stringing coax cable from one end of the apartment to the other. We then 
proceeded to set up an IPX-based NetWare Lite network. In the days of DOS and 
the dreaded 640 K limit, we were quite proud of our little network. We ventured 
forth and immersed ourselves in the 3D world of DOOM well into the wee hours 
of the morning. 


To this day, DOOM and its descendants remain a nemesis to network managers. 
Bandwidth manager products, such as the one by Packeteer, even have a special 
data flow for DOOM. (This probably is to secure enough bandwidth for the DOOM 
players so that they are not slowed down by somebody's print job.) At any rate, 
computer games continue to be great tests for the speed and for the transport 
of |P and |PX protocols, as well as for the network manager trying to control 
them. In the lab or at home, the joys of playing the latest computer game over 
your new network can be a fun and rewarding experience. Plus, you can amaze 
your friends with your networking expertise. 
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Building the Framework for Internetwork Modeling—Configuring 
Key Components 


Every model that you construct in this book starts from a similar framework. Most models 
involve one or more LANs and WANs—of course, routers and hubs are needed for this. You also 
need a device for local or remote access to the model, along with a test application to run or 
test the model. Thus, your framework for most models consist of routers, hubs, a Frame Relay 
switch, an access server, and a couple of workstations. From this framework, you build and 
design many models, making only subtle changes to the network topologies. There is a logical 
process to go through when constructing this initial framework: 


Step 1. Gain privileged level access to devices in the model. This includes using 
and modifying the 16-bit boot register to gain privileged level access to a router's 
configuration. 


Step 2. Upgrade the Cisco |OS Software to the model's requirements. This 
includes copying a new IOS image to Flash memory. 


Step 3. Configure local and remote access to the model. This includes configuring 
an access server and configuring analog dialup access to the lab. 


Step 4. Configure LAN and WAN devices. Every model will require slightly different 
LAN and WAN configurations. This will require only minor cable movement, though, so 
your primary focus will be on the initial configuration of a Frame Relay switch and its 
permanent virtual circuits (PVCs). 


Step 5. Configure test applications and test networks. This includes setting up 
Microsoft Windows 95/98/2000 networking and configuring network protocols such as 
TCP/IP, |PX, and Net BEUI. You will also learn about the use of route generators. 


Gaining Privileged Access: The 16-Bit Boot Register 


| think that one of the best-kept secrets of Cisco routers and switches is the 16-bit boot 
register. The 16-bit register is located on almost every Cisco platform in one variation or 
another. For example, this is the same register that was set by jumpers on the AGS series 
routers in the early 1990s. It is the same register that is found in the Catalyst switches in 2001. 
And, for the most part, it is the same register on all Cisco routers, sometimes masked in a 
utility called CONFREG. 


Another common example of using the boot register is during password recovery. The boot 
register, actually bit 6, is the bit that you flip when you change the register from 0x2102 to 
0x2142 during password recovery. During password recovery, bit 6 is set to ignore NVRAM on 
startup. This is perhaps the most common use of the register. Some other uses of the boot 
register include the following: 


e Recovering a lost password 

e Enabling or disabling the console Break key 

e Allowing manual boot of the OS using the B command at the bootstrap program (ROM 
monitor) prompt 

Changing the router boot configuration to allow a Flash or ROM boot 

Performing maintenance testing from the ROM monitor 

Loading an image into Flash memory 

Permanently disabling a router 
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Because the boot register represents the "keys" to your router, it is important to explain the 
entire register rather then covering just bit 6. 


To display the boot register, key in the show version command. The boot register is displayed 
at the bottom of the text. Example 1-6 demonstrates the show version command. 


Example 1-6 The show version Command, with a Boot Register Set to 
Boot to ROM, 0x2101 


router (boot) #show version 

Cisco Internetwork Operating System Software 

IOS (tm) 3000 Bootstrap Software (IGS-RXBOOT), Version 10.2(8a), RELEASE SOFTWAR 
BE. (fel) 

Copyright (c) 1986-1995 by cisco Systems, Inc. 

Compiled Tue 24-Oct-95 15:46 by mkamson 

Image text-base: 0x01020000, data-base: 0x00001000 


ROM: System Bootstrap, Version 5.2(8a), RELEASE SOFTWARE 


router uptime is 34 minutes 

System restarted by power-on 

Running default software 

cisco 2500 (68030) processor (revision L) with 14332K/2048K bytes of memory. 
Processor board serial number 03071163 with hardware revision 00000000 
X.25 software, Version 2.0, NET2, BFE and GOSIP compliant. 

ISDN software, Version 1.0. 

1 Ethernet/IEEE 802.3 interface. 

2 Serial network interfaces. 

1 ISDN Basic Rate interface. 

32K bytes of non-volatile configuration memory. 

16384K bytes of processor board System flash (Read/Write) 


Configuration register is 0x2101 


router (boot) # 


The boot register is formatted with the most-significant bit on the right, as illustrated by Figure 
1-9. This figure also shows how the default settings of 0x2102 are derived on Cisco routers. 


Figure 1-9. Default Settings of the 16-Bit Boot Register 
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Briefly stepping through the default settings of the register, you can see that bits 1, 8, and 13 
are set to 1, or the ON position. Having bit 1 set then sets the boot portion of the register to a 
hexadecimal value of 2. This tells the router to boot from Flash if a valid 1OS is found there. 
Having bits 4 through 7 set to 0 enables the router to boot normally; from NVRAM, preserve 
the banner and set "all 1s" as the broadcast. Bit 8 tells the router that the Break key is 
disabled. The rest of the register sets the network broadcast to 1s, sets the console baud rate 
to 9600, and determines how the router responds to a netboot failure. As mentioned 
previously, the most common use of this register is the flipping of bit 6, causing the baa to 


ignore the startup config stored in NVRAM. Again, this is the same procedure used in password 
recovery. 


Table 1-3 illustrates the entire register and its settings in detail. Refer to this table when 
reading the following detailed descriptions of the boot register. 


Table 1-3. The Entire 16-Bit Boot Register with Default Settings 
Default 
Meaning Setting 
Boot Field: 0010 
0x0 = Boot ROM monitor. 


0x1 = Boot from onboard ROM, or boot to boot mode, if a 
subset of the |OS exists. 


0x2 to OxF 

Causes the following (listed in order of precedence): 

Boot from Flash, if a valid 1OS file exists. 

Follow boot system commands found in the configuration. 


Use the register value to form a filename from which to 
netboot a system image from. 


4 Fast boot: Force load through the boot system 0 
commands found in the configuration. 

5 High-speed console: 1 = console operates at 19.2 /|0 
or 38.4; works with bits 11 and 12. 

6 Ignore startup-config file: 1 = ignore NVRAM. 0 


5 OEM bit: 1 = disabling the display of the Cisco 0 
banner on startup. 
(8 Break key: 1 = disable. [1 
9 Not used. [0 
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11-12 


11-12 
Cont. 


Netboot broadcast format: 


Setting bit 10 = 1 causes the processor to use an all-zeros 
broadcast. 


Console baud rate: 


Bit5 =1 
Bit 11 = 1 
Bit 12 = 0 


Console baud rate = 38,400 


Bit5 =1 
Bit 11 =0 
Bit 12 =0 


Console baud rate = 19,200 


Bit5 =0 
Bit 11 =0 
Bit 12 =0 


Console baud rate = 9600 


Bit5 =0 
Bit11=0 
Bit 12 =1 


Console baud rate = 4800 


00 
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Bit 11=1 
Bit 12 =1 
Console baud rate = 2400 


Console baud rate = 1200 


13 Response to netboot failure: 1 = boot from ROM 1 
after netboot failure, 0 = continue to netboot. 
Netboot subnet broadcast: 


Setting bit 14 = 1 forces a subnet broadcast. 


Enable diagnostic messages: 1 = ignore NVRAM 
and display diagnostic messages. 


Boot Field (Bits 0 Through 3) 


The boot field controls the booting of the router. This field starts with the first 4 bits on the 
right. If this field is set for 0x0, decimal 0, the router will boot to ROM monitor mode. For 
example, setting the register for 0x2100 causes the router to boot to ROM monitor mode. 
Setting this value to 0x1 causes the router to boot from its onboard ROM. This ROM may 
contain a full 1|OS, such as in the 7000 series, or a subset of the 1OS, as in the 2500 series. The 
prompt, when in boot mode, is represented with (boot) behind the router's host name. 


If you set the boot field to a value of 2 through F, and if there is a valid system boot command 
stored in the configuration file, the router boots the system software as directed by that value. 
If you set the boot field to any other bit pattern, the router uses the resulting number to form a 
default boot filename for netbooting. The router creates a default boot filename as part of the 
automatic configuration processes. To form the boot filename, the router starts with cisco and 
links the octal equivalent of the boot filename, a dash, and the processor-type name. A Cisco 
4000 with the bit pattern of 0x1 set in the first octet will try to load a TFTP file named Cisco2- 
4000. Table 1-4 lists the default boot filenames or actions for the processor when setting the 
boot field bits. The xxxx stands for the processor type—for instance, in Cisco 4000, xxxx = 
4000. 


Table 1-4. Default Boot Filenames 
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| Action/ Filename | Bit 3 | Bit 2 | Bit 1 | Bit O 
[Boot to ROM monitor ; : 0 [0 

[Boot from ROM 

Icisco2- XXXX cE : [2 [0 
Icisco3- XXXX 0 [2 [2 
Icisco4- XXX [2 [0 [0 


Icisco5- XXXX 0 [2 0 1 


ie 0 [1 1 (0 
CiSCO7-XXXX 0 [2 i [2 
Icisco10-xxxx 1 0 0 0 
Icisco1 1-xxxx 1 0 3 
Icisco12-xxxx 1 (0 [2 0 
cisco13-xXxxx 1 (0 1 1 
Iciscol4-xxxx 1 [1 0 [0 
Icisco15-xxxx 1 [1 0 [2 
Icisco16-xxxx 1 1 i) 0 


[cisco17-xxxx [1 [2 [2 [2 


Fast Boot/Force Boot (Bit 4) 


Setting this bit forces the router to load the Cisco |OS Software found in the configuration set 
by the boot system flash command. If no Cisco |OS Software matches the filename set by 
this command, the router will boot to boot mode. For example, adding the line boot system 
flash c2500-js56-1.120-3.bin forces the router to look for the file c2500-js56-1.120-3.bin in 
Flash memory. If an exact match of this filename isn't found, the router will boot in boot mode. 


High-Speed Console (Bit 5) 


The setting of bit 5 works in conjunction with bits 11 and 12. Setting this bit is for high-speed 
console access above 9600 bps. When this bit is set, you can connect to the console port at 
speeds of 19,200 bps and 38,400 bps. For a complete listing of how the jumper works in 
conjunction with bits 10, and 11, see Table 1-6. 


CAUTION 


Bit 5 is an "undocumented" bit for a reason. The console port is critical to router 
operation and troubleshooting. The higher the data speeds are, the more sensitive 
the connection is and the higher the probability is that you will not be capable of 
connecting to the router at these high speeds. If you do not have Telnet access or 
another "back door" into the router enabled, the consequences can be dire. The 
gains from operating the console port at 19,200 bps or 38,400 bps instead of 9600 
bps are minor. Keep in mind that the uses for this interface are for router key-ins 
and configuration; it is not necessary to have high-speed console access. Change 
this bit with extreme caution. 


of 


Ignore NVRAM (Bit 6) 


Setting this bit forces the router to ignore the configuration file in NVRAM, called the startup- 
config. When you ignore NVRAM, you essentially are ignoring the startup-config. You can still 
view the startup-config with the show command, but the configuration will be absent from the 
running-config. This is also the bit that is flipped during password recovery. 


OEM Bit (Bit 7) 


This bit was created for Original Equipment Manufacturers (OEMs) versions of the routers. By 
setting this bit, the Cisco Systems, Inc. banner will be ignored. If the 1OS has encryption 
software on it, the encryption warning will still be displayed. 


Break Key (Bit 8) 


Setting this bit disables the Break key. If you set this bit to 0, then at any time during the 
routers uptime—not just during the boot process—you can halt the operating system with the 
press of a single key. This is a powerful setting and should not be changed. Disabling the break 
—it is disabled by default—does not affect the Break key during the first 60 seconds of 
initialization. During this time, the Break key will still halt the router. 


Reserved (Bit 9) 
This bit is currently not in use. 


Netboot Broadcast Format (Bits 10 and 14) 


Setting bits 10 and 14 controls how the routers and switches handle subnet and host 
broadcasts. The default broadcast address is all 1s in the host or subnet destination address. 
Changing these bits allows for backward compatibility for many older UNIX hosts, such as 
Berkley UNIX 4.2BSD. Most IP implementation today uses a 1s compliment for broadcast 
messages, so you probably will never modify these settings. Table 1-5 illustrates the use of bit 
10 and bit 14. 


Table 1-5. Configuration Settings for Broadcast Address Control, Bit 10 
and Bit 14 


| Bit 14 | Bit 10 | Address (<net><host>) 
(0 (0 |<1s> <ls> 
(0 [1 [<0s> <ls> 
[2 0 |<net> <ls> 
[2 [2 |<net> <Os> 


System Console Terminal Baud Rate Settings (Bits 5, 11, and 12) 


Bits 5, 11, and 12 control the baud rate (bps) of the console port. The routers are shipped with 
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this setting to 9600, which has bits 5, 11, and 12 off, or set at 0. Table 1-6 shows the baud 
rate settings. For example, to increase the baud settings of the routers console port, use a 
register of 0x2122 for 19.2 access. 


Table 1-6. Configuration Settings for System Console Baud Rate 


| Bit 5 | Bit 11 L Bit 12 | Console Baud Rate 
[2 [2 38,400 bps 
; c E 9,200 bps 


00 95 


OR R200 bps 
OR R40 bps 


Netboot Failure Response (Bit 13) 


Setting bit 13 causes the router to load the Cisco |OS Software from the default location after 
five netboot failures. The default for this bit is on, or 1, which is why most of the routers' jump 
registers start with 2. Setting this bit to 0 causes the router to continue to netboot and never 
look at the ROM for booting. 


Display Factory Diagnostics (Bit 15) 


Setting bit 15 causes the router to display factory diagnostic messages. Setting this bit also 
forces NVRAM to be ignored. To display these diagnostic messages, configure the register at 
OxA102. The A sets bit 15 and bit 13, forcing diagnostics messages to appear during 
initialization. 


Understanding the Boot Process 


This next section can be found in a similar format on the Cisco documentation CD that comes 
with all new Cisco routers. Although everything can be found on the CD, this section is 
important enough to highlight: 


When a router is powered on or rebooted, the following events happen: 


e The ROM monitor initializes. 
e The ROM monitor checks the configuration register boot field (the lowest 
4 bits in the register.) 


- If the boot field is 0x0, the system does not boot an 1OS image 
and waits for user intervention at the ROM monitor prompt. 


- If the boot field is 0x1, the ROM monitor boots the boot helper 
image. (On some platforms the boot helper image is specified by 
the BOOTLDR environment variable. ) 
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- If the boot field is Ox2 through OxF, the ROM monitor boots the 
first valid image specified in the configuration file or specified by 
the BOOT environment variable. 

e When the boot field is Ox2 through OxF, the router goes through each 
command in order until it boots a valid image. If bit 13 in the 
configuration register is set, each command will be tried once. If bit 13 is 
not set, the Boot system command specifying a network server will be 
tried up to five more times. The timeouts between each consecutive 
attempt are 2, 4, 16, 256, and finally 300 seconds. If it cannot find a 
valid image, the following events happen: 


- If all boot commands in the system configuration file specify 
booting from a network server and all commands fail, the system 
attempts to boot the first valid file in Flash memory. 


- If the boot-default- ROM-software option in the configuration 
register is set, the router will start the boot image (the image 
contained in boot ROM or specified by the BOOTLDR environment 
variable). 


- If the boot-default- ROM-software option in the configuration 
register is not set, the system waits for user intervention at the 
ROM monitor prompt. You must boot the router manually. 


- If a fully functional system image is not found, the router will 
not function and must be reconfigured through a direct console 
port connection. 

e When looking for a bootable file in Flash memory: 


- The system searches for the filename in Flash memory. If a 
filename is not specified, the software searches through the entire 
Flash directory for a bootable file instead of picking only the first 
file. 


- The system attempts to recognize the file in Flash memory. If 
the file is recognized, the software decides whether it is bootable 
by performing the following checks: 


mw For run-from-Flash images, the software determines 
whether it is loaded at the correct execution address. 

m For run-from-RAM images, the software determines 
whether the system has enough RAM to execute the image. 


This process changes on platforms with dual processor cards or dual Flash cards, such as those 
that are found on the 7000 series or in the Catalyst RSM. Figure 1-10 diagrams this rather 
complicated process as it is found on most platforms (except those noted). 


Figure 1-10. Router Boot Process 
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Accessing the Register 


The boot register is a 16-bit register represented in hex to the router. The router make and 
model determine how the register is accessed. As mentioned previously, the AGS used 16 
jumpers to set this register. Every router and switch allows access to the register through the 
configuration, assuming that you have privileged-level access. Switches work much in the same 
way as routers. First, you will learn about accessing the register on Catalyst switches, and then 
you will learn about routers. 
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Accessing and Configuring the Register: Catalyst Switches 


For the most part, the 16-bit register is identical to its cousin found in the router. The 
differences are slight. Most of the bits that are used in netbooting are used for broadcast 
control and are not used on the Catalyst switches. Bit 6 operates differently on the Catalyst 
than it does on the router. Setting Bit 6 clears the configs from NVRAM, which is the same as 
entering the clear config all command—that is, it clears the entire configuration stored in 
NVRAM the next time the switch is restarted. 


The initialization process on the Catalyst 5000 series Supervisor Engine III and the Catalyst 
4000, 2948G, and 2926 series switches involves two software images: the ROM monitor and 
the supervisor engine system code. When the switch is reset, the ROM monitor code is 

executed first. Then, depending on the boot register settings in NVRAM, the switch either 
remains in ROM monitor mode or loads the supervisor system image. If a fatal exception error 
occurs during powerup, the switch remains in ROM monitor mode. Figure 1-11 illustrates the 16- 
bit boot register for the Catalyst series of switches. Table 1-7 provides detailed descriptions of 
the boot register. 


Figure 1-11. The Entire 16-Bit Boot Register for Catalyst Switches with 
Default Settings 


Bit | Bit | Bit | Bit | Bit | Bit | Bit | Bit | Bit Bit | Bit 
18 | 14)13 |} 12 )11)/10/9 |8 |7 3 |2 
ay |, RT | EES | ET 


Table 1-7. Catalyst Switch Boot Register Bit Meanings and Default 


Settings 
Default 
Bit Meaning Setting 


Boot field: 1111 


0x0 = Boot ROM monitor. 


0x1 = Boot from onboard ROM, or boot to boot mode if a subset 
of the 1OS exists. 


Ox2 to OxF 
Causes the following (listed in order of precedence): 
Follow boot system commands found in the configuration. 


If a boot image in the BOOT environment variable list is not 
found, boot in ROM monitor mode. 
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Reserved. 


Clear NVRAM: 1 = Clear NVRAM. 


OEM bit: 1 = disabling the display of the Cisco banner 
on startup (Not used.) 


8 [Breakkey: l=disablee sss 8 [Breakkey: l=disablee sss 1 = disable. 


E [Unsupported baud rate. 
10 [ P will use an all-zeros broadcast. (Not used.) 


11- Console baud rate: 
12 


ee | 
— 


00 = 9600 01 = 4800 
10 = 1200 1200 


On the Catalyst 4000 and 2948G, this speed is fixed at 9600. 


13 Boots default Flash if network boot fails. (Not used.) 
Netboot subnet broadcast: 


Setting bit 14 = 1 forces a subnet broadcast. (Not used.) 


Enable diagnostic messages: 1 = ignore NVRAM and 
display diagnostic messages. (Not used.) 


The default register is set for 0x010f. This allows the system to boot from the image specified 
in the BOOT environment variable; the console will operate at 9600 baud, and any 
configuration in NVRAM will be loaded. To display the current register settings, use the show 
boot [module_number] command. Example 1-7 shows how to display the current configuration 
register and BOOT environment settings. 


Example 1-7 Demonstration of the show boot Command 


Console>(enable) show boot 

BOOT variable = slot0O:cat5000-sup3.4-2-1.bin,1;bootflash:cat5000-sup3.3-2- 
1lb.bin, 1;bootflash:cat5000-sup3.4-1-2.bin,1; 

Configuration register is 0x1l0f 

Ignore-config: disabled 

Console baud: 9600 

Boot: image specified by the boot system commands 


Console> (enable) 
The following is list of register-specific commands for the Catalyst family of switches: 
e set boot config-register Oxvalue [mode_num] 


This command directly configures the boot register at the bit level. This commen 


affects all the bits in the register by modifying the entire boot register at once. 
set boot config-register baud {1200 | 2400 | 4800 | 9600}[module_number] 


This configures the ROM monitor console port baud rate. The ROM monitor uses the 
baud rate specified in the configuration register only if it is different from the baud rate 
specified by the set system baud command. 


set boot config-register ignore-config enable 


This command clears the entire configuration stored in NVRAM the next time the switch 
is restarted. This is essentially the same as using the clear config all command, 
followed by a reload. 


set boot config-register boot {rommon | bootflash | system}[module_number] 
This command determines what boot method the switch will use during the next startup: 
- rommon = Boot to the ROM monitor 
- bootflash = Boot from the first image stored in the onboard Flash 


- system = Boot from the image specified in the BOOT environment variable. 
This is the default setting. 
set boot system flash device: [filename] [prepend] [module_number] 


This command specifies an image to add to the BOOT environment variable. This also 
specifies what device that image exists on. 


clear boot system flash device: [filename][module_number] 
This command clears a specific image from the BOOT environment variable. 
clear boot system all[module_ number] 


This command clears the entire BOOT environment variable. 


Accessing and Configuring the Register: Cisco Routers 


To set the register by the configuration mode, enter config-register <0x0000-OxFFFF>. 
Example 1-8 demonstrates how to change the configuration register from 2102 to 2142. This 
forces the router to ignore NVRAM during its initialization. To see if the configuration settings 
have taken effect, perform the show version command after changing the register. 


TIP 


You should always check and document the current configuration register setting 
before changing it. This might come in handy if you have problems. 
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Example 1-8 Changing the Boot Register Through the Configuration 


Documenting the current setting 

router# 

router#show version 

Cisco Internetwork Operating System Software 

IOS (tm) 2500 Software (C2500-JS56-L), Version 12.0(3), RELEASE SOFTWARE (fcl) 
Copyright (c) 1986-1999 by cisco Systems, Inc. 

*ex text omitted *** 

32K bytes of non-volatile configuration memory. 

16384K bytes of processor board System flash (Read ONLY) 


Configuration register is 0x2102 
router# 


Change the setting to 0x2142. 


router#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
router (config) #config-register 0x2142 

router (config) #*Z 

router# 

router#show version 

Cisco Internetwork Operating System Software 

IOS (tm) 2500 Software (C2500-JS56-L), Version 12.0(3), RELEASE SOFTWARE (fcl) 
Copyright (c) 1986-1999 by cisco Systems, Inc. 

**xe* text omitted *** 

32K bytes of non-volatile configuration memory. 

16384K bytes of processor board System flash (Read ONLY) 


Configuration register is 0x2102 (will be 0x2142 at next reload) 


TIP 


Whenever you change the boot register from the configuration mode, you are 
prompted to save your configuration before you reload the router. This prompt is 
generated from entering the configuration mode and exiting, regardless of any 
changes made to the configuration. The register setting is not part of the startup- 
config or running-config, so it is not necessary to save the configuration for the 
new jump register setting to take place. 


Accessing and Configuring the Register: ROM Monitor 


If you cannot access the router's configuration, such as in a password-recovery situation, you 
can force the Cisco |OS Software to halt and go into ROM monitor mode. To enter ROM monitor 
mode, you must send a break signal to the router. By default, the Break key is disabled by the 
boot register; consequently, a restart of the router is needed. Almost all Cisco routers and 
switches can be interrupted by sending the break signal during the first 60 seconds of 
initialization. There are many ways to send the break signal and to interrupt router and switch 
operations, the most common of which are documented in Table 1-8. 
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Table 1-8. Standard Break Key Combinations 


Terminal- 
Emulation Operating 
Software Platform System Key Combination 
Hyperterm IBM-compatible |Windows 9x Ctrl-F6-Break 


(version 595160) 


Kermit Sun workstation |Solaris (Ctrl-\L 

Kermit Sun workstation |Solaris [Ctrl-\B 

[MicroPhone Pro BM-compatible |Windows 9.x Ctrl- Break 
Minicom IBM-compatible /Linux (Ctrl-A-F 
ProComm Plus {I BM-compatible DOS or Windows [Alt-B 

Telix [ BM-compatible |DOS - 

Telnet to Cisco [ BM-compatible |— 
[Teraterm [ BM-compatible |Windows 9.x 


Hyperterm IBM-compatible |Windows 9.x Break 


peers | [Hyperterm  ——(|IBM-- compatible |Windows 9.x Ctrl-Break 


Sun workstation |Solaris Ctrl-], then Break or 
Ctrl-C 


#0 
VT 100 a Data a 


Hypterm |BM-compatible Wn dGws NT Si 6 Shift-4 Shift-B 
| | 3 “$B) 


Z-TERMI NAL Mac Apple [Command-Bséd B 

— Break-Out Box |— Connect pin 2 coma mit) 
to +V for half a 
second 


Cisco to aux Control-Shift-6, then 
port 3) 


— = IT BM-compatible — IBM-compatible | Ctrl-Break 


If your portable or laptop computer is using Windows 95/98/2000 with HyperTerm, the break 
signal is usually issued by pressing the Function key and the Break key, sometimes located on 
the Page Down or Pause key. 


On a full-size 101 keyboard with Windows 95/98 with HyperTerm, the break signal is issued by 
pressing the Ctrl-Break/Pause key. 


On Windows NT, you must configure NT to send the break signal with a function key. Set the 
break by entering the characters *$B (Shift 6, Shift 4, and uppercase B). HyperTerm 5.0 
private edition sends the break for the windows NT platform without any additional 
configuration. 


To access the register of a Catalyst 5000 or 2926G series switch, you can enter ROM monitor 
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mode by restarting the switch and then pressing the Break key during the first 60 seconds of 
initialization. On the Catalyst 4000 and 2948G series switches, you can enter ROM monitor 
mode by restarting the switch and then pressing Control-C during the first five seconds of 
initialization. 


When using any other terminal-emulation software, consult the manufacturer's instructions on 
sending a break signal. 


When you have successfully sent the break signal, the router prompt will change to a > 
character or a rommon x > prompt. There are two prompts because there are two types of 
ROM monitors. One is built around the earlier 2000 series boards. It requires more of a manual 
manipulation of the boot registers. The other type of ROM monitor is built around the newer 
3600 and RISC-based platforms. This ROM monitor uses a utility called CONFREG to manipulate 
the boot register. Table 1-9 lists some common router types and the type of ROM monitor used. 


The easiest way to tell what type of ROM monitor is used in your router is to simply key in the ? 
for help. If the CONFREG utility appears, execute it by typing in CONFREG. 


Table 1-9. ROM Monitor Compatibility Matrix 


| CONFREG ROM Monitor | Basic ROM Monitor 


Cisco 1003 series Cisco 2000 series 
Cisco 1600 series Cisco 2500 series 
Cisco 3600 series Cisco 3000 series 


Cisco 4500 series [Cisco 4000 series with 680x0 

Cisco 7200 series [Cisco 7000 series 10.0 ROM 

Cisco 7500 series Cisco IGS series running |OS 9.1 in ROM 
[ DT Orion-based router 
‘AS5200 and AS5300 platforms 


First, you will learn about the Basic ROM monitor, and then you will learn about the utility called 
CONFREG. When you have successfully transmitted a break signal, you should get a screen that 
resembles Example 1-9; also note the Abort at message. 


Example 1-9 Example of a Successful Break into ROM Monitor, Followed 
by the h or Help Command 


System Bootstrap, Version 5.2(8a), RELEASE SOFTWARE 
Copyright (c) 1986-1995 by cisco Systems 
2500 processor with 14336 Kbytes of main memory 


SESS SE sae U ae Ee)) 
> 
>h 
5 Toggle cache state 
B [filename] [TFTP Server IP address | TFTP Server Name] 
Load and execute system image from ROM or from TFTP server 
C [address] Continue execution [optional address] 
D/SMLV Deposit value V of size S into location L with modifier M 
E/SML Examine location L with size S with modifier M 
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G [address] Begin execution 

H Help for commands 

I Initialize 

K Stack trace 

L [filename] [TFTP Server IP address | TFTP Server Name] 


Load system image from ROM or from TFTP server, but do not 
begin execution 

@) Show configuration register option settings 

P Set the break point 

S Single step next instruction 

T function Test device (? for help) 


Deposit and Examine sizes may be B (byte), L (long) or S (short). 
Modifiers may be R (register) or S (byte swap). 


Register names are: DO-D7, AO-A6, SS, US, SR, and PC 
> 


The abort message first conveys that the router has aborted and that you successfully halted 
the router OS. The second indication that you are in the ROM monitor mode is the > prompt. 
Also in Example 1-9, an h was entered to display the help listing; this key is the same as the ? 


key. Most of the ROM monitor is designed for low-level hardware and software debugging, but a 
couple of commands are worth mentioning: 


e H— Displays the help messages, as in Example 1-9. 

e I— Initializes the router. It is the same as the reload command. 
e $— Toggles the cache; used for debugging by the TAC. 

e P— Sets the break point; used for TAC diagnostics. 

e S— I|s a single-step instruction used for TAC diagnostics. 


e T function— Use the ? key behind the T command to perform a low-level test of a 
specific components. This usually performs a detailed hardware memory diagnostic. 


e B— Allows manual booting from the ROM monitor: 


- B flash— Boots the first file in Flash memory. 
- B filename [TFTP host]— Boots over the network using TFTP. 
- B flash filename— Boots the file (filename) from Flash memory. 


e L— Works the same as the B command, but the router will not begin execution of the 
code. 


e O-— Examines the 16-bit boot register. 


e O/R 0x0000— Sets the boot register by using a manual hex setting. For example, O/R 
0x2102 will set the register to its default. 


e D/S ML V— Deposit value V of size S into location L with modifier M. 
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e E/S ML— Examines location L with size S with modifier M. E/ S 2000002 examines the 
boot register directly from memory. 


At this time, you can verify whether you have a router that supports the CONFREG utility or one 
that supports only basic ROM monitor commands. By looking at the ROM monitor prompt, you 
can determine this. By keying in the ? command, you can determine whether CONFREG is 
supported. For example, in Example 1-10, notice that the prompt is a >, the greater-than sign. 
This prompt is a good indication that you might have to use basic ROM monitor commands to 
change the boot register. One last check is to simply key in the ? command for help, as the 
example demonstrates. 


Example 1-10 Another Example of a Successful Break into ROM 
Monitor, Followed by the ? or Help Command, Showing the Presence of 
the CONFREG Utility 


Abort at 0x10200C2 (PC) 


> 
S Toggle cache state 
B [filename] [TFTP Server IP address | TFTP Server Name] 
Load and execute system image from ROM or from TFTP server 
C [address] Continue execution [optional address] 
D/SMLV Deposit value V of size S into location L with modifier M 
E/SML Examine location L with size S with modifier M 
G [address] Begin execution 
H Help for commands 
I Initialize 
K Stack trace 
L [filename] [TFTP Server IP address | TFTP Server Name] 
Load system image from ROM or from TFTP server, but do not 
begin execution 
@ Show configuration register option settings 
P Set the break point 
3 Single step next instruction 
T function Test device (? for help) 


Deposit and Examine sizes may be B (byte), L (long) or S (short). 
Modifiers may be R (register) or S (byte swap). 

Register names are: DO-D7, AO-A6, SS, US, SR, and PC 

> 


Example 1-11 shows the output from the ? command showing the CONFREG utility. Therefore, 
to configure this router's boot register, you use CONFREG. Notice in Example 1-11 the prompt 
of rommon. This is a good indication that CONFREG is supported. 


Example 1-11 The ? Command Used on a Router That Supports 
CONFREG 


**x* System received an abort due to Break Key *** 
signal= 0x3, code= 0x0, context= 0x6033f2b8 

PC = 0x6005eba4, Cause = 0x20, Status Reg = 0x34408302 
rommon 1 > 

rommon 1 > ? 


alias set and display aliases command 
boot boot up an external process 
break set/show/clear the breakpoint 
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confreg configuration register utility 


cont continue executing a downloaded image 
context display the context of a loaded image 
cookie display contents of cookie PROM in hex 
dev list the device table 

air list files in file system 

dis disassemble instruction stream 

dnld serial download a program module 

frame print out a selected stack frame 

help monitor builtin command help 

history monitor command history 

meminfo main memory information 

repeat repeat a monitor command 

reset system reset 

set display the monitor variables 

Stack produce a stack trace 

sync write monitor environment to NVRAM 
sysret print out info from last system return 
unalias unset an alias 

unset unset a monitor variable 


rommon 2 > 


At times, reading the English wording of CONFREG can actually be harder to understand than 
just manipulating the bits in the register. To help understand which bits the questions in 
CONFREG correspond to, consult Table 1-10. 


Table 1-10. CONFREG to BIT Comparison 


| CONFREG Text |Bit(s) Set | Default Setting 


enable "diagnostic mode"? y/n [n]: 15 Off 


lenable “use net in IP bcast address"? y/n [n]: 14 Off 
disable "load rom after netboot fails"? y/n [n]: [13 [On 


enable "use all zero broadcast"? y/n [n]: 10 Off 


lenable "break/abort has effect"? y/n [n]: 8 Off 
lenable "ignore system config info"? y/n [n]: 6 Off 


change console baud rate? y/n [nl]: 11&12 Off and Off 


change the boot characteristics? y/n [n]: 0-3 Ox2 


Password Recovery: Routers 


When you have a solid understanding of how the boot register works, password recovery 
becomes straightforward. For all the router platforms, the procedure involves simply changing 
bit 6, which ignores the startup-config in NVRAM, and then reloading the router. When the 
router reboots, it will no longer have a running-config. The configuration is still stored in 
NVRAM and can be viewed by performing the show startup-config command from Enable 
mode. Because there is no running-config, there will be no enable password. Therefore, you 
can enter Enable mode and copy the startup-config to the running-config, with the copy 
startup-config running-config command. At this time, remember to change the register 
back, set the enable password, bring up the interfaces (which will be down), and save the new 
configuration. This entire process is outlined in the step list that follows. 
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As mentioned previously, the router will always accept a break signal if sent during the first 60 
seconds of initialization, regardless of whether bit 8 is set. With this in mind, the following 
procedure will recover most routers: 


Step 1. Attach a PC or PDA with terminal-emulation software to the router's console 
port through a Cisco rolled cable. 


Step 2. Power-cycle the router. 


Step 3. Issue a break signal by pressing the Break key, or by executing one of the 
other ways mentioned, within 60 seconds of initialization. 


Step 4. Determine what type of ROM monitor you have. |s CONREG supported? 
- If Basic ROM monitor: 


- Set bit 6: >O/ R Ox2142. This will set bit 6. Reload the router with the 
Initialize command. 


- If CONFREG is supported: 


Run the CONFREG utility: >CONFREG. Answer every question with the default 
or Enter, until you come to the question: Enable ignore system config info. 
Answer "yes" to this question. This will also set bit 6. Reload the router with the 
RESET command. 


Step 5. When the router reloads, it will try to run setup. Abort the setup utility with a 
Ctrl-C. 


Step 6. Enter Enable mode and do a copy startup-config running-config—for example 
#copy startup-config running-config. 


Step 7. Enter the configuration mode, and do the following: 
- Set the boot register back to its original configuration. 
- All interfaces will be shut down; bring up all interfaces to their normal state. 
- Set the enable password to a new value. 
- Save the new configuration. 


CAUTION 


Be careful after you have ignored NVRAM and reloaded the router. The router still 
has a configuration in NVRAM, and it is easy to overwrite this configuration with a 
slip of a keystroke. This is particularly easy for people of the "old school"—a simple 
wr instead of wr t will ruin the config stored in NVRAM. 


TIP 
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Make a backup copy of the current router configuration when modifying the 
registers or performing any work that could put the router configuration in 
jeopardy. Taking the small amount of time that it requires to perform this could be 
priceless if disaster strikes. 


Password Recovery: Switches 


Password recovery with switches is a little easier than with routers. During the first 30 seconds 
of initialization, the password and enable password is simply the Enter key. To recover a 
password on a Catalyst switch, follow this procedure: 


Step 1. Power-cycle the switch. 


Step 2. As soon as the switch loads, enter Enable mode. This is done by quickly typing 
in enable [Enter]. The switch will prompt you for a password. During the first 30 
seconds, the password is the Enter key. Therefore, simply press the Enter key. In 
Enable mode, set a new password with the set password command. When you're 
prompted for the old password, use the Enter key again. 


Step 3. 1n Enable mode, set a new enable password with the set enablepass 
command. When setting the enable password, you will be prompted for the old 
password; again, this is simply the Enter key. 


Upgrading the Cisco IOS Software 


At some time, either for some of the labs in this book or when in the field, you will have to 
upgrade the router's Cisco |OS Software. Upgrading Cisco |OS Software is a task that can be 
trivial if you know what you're doing. The Cisco |1OS image is stored on Flash memory, either in 
SIMMs or in credit-card modules. There are four items to account for before upgrading your 
router's Cisco |OS Software: 


e The router Cisco 1|OS release—must be Release 9.0 or later. (If this rule applies to you, 
it might also be time to upgrade to IP version 4.) 

e The amount of free space available on Flash. 

e The size of the new image, including its DRAM requirements. 

e A reachable IP address or name of the server to load the image from. 


To locate the amount of Flash space available on SIMMs, simply execute the show flash 
command. To view the contents on a credit-card module, enter dir [device]—for example, dir 
slot0: and/or dir slot1:, depending on which slot has the credit-card Flash in. Here are the 
common Flash commands and their PCMCIA equivalents: 


e show flash— Displays flash on SIMMs, as in Example 1-8. 
e dir [/all | / deleted | / long][device][filename]. 


- / all— Lists deleted, undeleted, and files with errors 
- / deleted— Lists deleted files only 


- / long— Lists files in a long, detailed format 


i2 


- device— Lists files on a specific Flash device: FLASH:, BOOTTFLASH:, SLOTO:, 
SLOT1: 


- filename— Names a specific Flash file to list 


e cd— Changes from one Flash device to another. 


e copy source-device: filename destination- device: filename— Copies files from one source 
to another. If no specific file is listed, you will be prompted later to enter the filename. 
This is the case when you copy TFTP to Flash. 


Here are some examples of Flash manipulation. 


e To change from one Flash device to another, key in the command cd—for example, cd 
SLOTI:. 

e To view the Flash on different devices, use the dir [/ all | deleted | long] command— 
for example, dir flash:, or simply dir. 


NOTE 


If you are using credit-card Flash, ensure that the write protect is located in the off 
position before you try to write to Flash. This can be done by moving the tab on 
the end of the Flash card. Not all Flash cards are the same; either the 
documentation or the Flash card itself will indicate which position is the write 
protect mode. 


Example 1-12 demonstrates the show flash command and a dir command on a router. 


Example 1-12 The show flash and dir Command 


router#show flash 


System flash directory: 
File Length Name/status 
il 10307412 c2500-j3s56-1.120-3.bin 
[10307476 bytes used, 6469740 available, 16777216 total] 
16384K bytes of processor board System flash (Read ONLY) 


router# 
router#dir 
Directory of flash:/ 


1 -rw- 10307412 <no date> c2500-j3s56-1.120-3.bin 


16777216 bytes total (6469740 bytes free) 
router# 


In this example, the Cisco |OS Software is c2500-js56-1.120-3.bin, and its length is 10307412 
bytes. This Flash image leaves only 6.46 kB left. Therefore, when you upgrade the router's 
Cisco |OS Software, you need to delete the old version. 


After you determine what type of Flash device the router has and how much Flash memory is 
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available, you can plan for the Cisco |OS Software upgrade. The first thing in planning for an 
10S upgrade is to determine the requirements in terms of Flash main or shared DRAM memory. 
Every IOS has different Flash and DRAM requirements. The only way to verify the exact 
requirements of the IOS is to look it up on Cisco's Web page. 


If you have the proper access and authority to upgrade your Cisco |OS Software from Cisco, 
you can find new software releases in the Software Center of Cisco's home page under Service 
& Support. By clicking on the Software Center, you will be prompted through a series of 
questions called the Cisco |OS Planner. The planner will guide you through the process by 
slowly narrowing your choices of a new IOS. In this example, the IP version has been chosen 
for a Cisco 2600 series router—specifically, 12.0.9. Notice the minimum memory requirements 
of 4 MB of Flash and 20 MB of DRAM memory, as illustrated in Figure 1-12. You must be logged 
on and have proper authority to view and download Cisco |OS Software. 


Figure 1-12. Example of a Cisco Web Download of 1OS 
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It is important to mention that the Cisco Web page or the Cisco TAC is the first and last 
authority when it comes to Cisco |OS Software memory requirements. Assuming requirements 
across multiple platforms and even within a platform is not recommended. Let's use the 
example in Figure 1-12 to demonstrate this. The same Cisco |OS Software release, 12.0.9, ona 
Cisco 2500 series platform requires 8 MB of Flash and only 4 MB of DRAM memory. This is 
exactly why you must verify the requirements of each |OS release to be certain that it will work 
in the router you're trying to upgrade. 


The last phase will be to ensure that there is a valid TFTP server with the new Flash image, in 
that it is reachable. Finally, the router is ready to upgrade. To copy Cisco |OS Software from a 
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TFTP server to the router, use the copy tftp flash command. Before you perform this 
command, check the following: 


e The TFTP server's IP address 

The Cisco |OS Software name as it exists on the server 

e That the router can ping the TFTP server (again, this should be a locally connected 
network) 


When performing the copy tftp flash command, you will be asked a series of questions, 
basically matching the preceding list. 


NOTE 


With Cisco |OS Software Release 11.0, Cisco introduced a more "English-like" 
command structure for handling files. Instead of configure memory, it uses copy 
startup-config running-config to write the configuration to NVRAM. Table 1-11 


provides a comparative list of the old commands and their new command 
counterparts. After looking at the list, it becomes clear why Cisco made the change. 


Table 1-11. Changes to Cisco |OS Software File Commands 


| Old Command New Command 
[configure memory copy startup-config running-config 
[configure network copy {rcp | tftp} running-config 
configure overwrite-network copy {rcp | tftp} startup-config 
[copy erase flash erase flash 


copy verify or copy verify verify flash, verify (cisco 7000 and Cisco 
flash 7500) 


[copy verify bootflash verify boot flash 

show configuration show startup-config 

ltftp- server system tftp-server 

write erase erase startup-config 

lwrite memory copy running-config startup-config 
lwrite network copy running-config {rcp | tftp} 
write terminal show running-config 


In the next example, you will be upgrading the |OS of the access server. For this example, the 
new Cisco IOS file is c2500-js56-1.120-3.bin and is located on a TFTP server at address 
206.191.241.45. According to Cisco, the new Cisco |OS Software requires 16 MB of Flash and 8 
MB of DRAM Memory. 


As mentioned previously, first you must verify that you have |OS 9.0 or later on your router. 
You also must verify that there is enough Flash and Main memory to run the new Cisco |OS 
Software. To do this, use the show version and show flash commands. Example 1-13 is a 
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good exhibition of these commands. 


Example 1-13 Verifying Flash and DRAM Memory with the show version 
and show flash Commands 


skynet_access_l#show version 

Cisco Internetwork Operating System Software 

IOS (tm) 3000 Software (IGS-INR-L), Version 10.3(7), RELEASE SOFTWARE (fcl) 
Copyright (c) 1986-1995 by cisco Systems; Inc. 

Compiled Wed 01-Nov-95 12:40 by vatran 

Image text-—base: 0x03022C14, data-base: 0x00001000 


ROM: System Bootstrap, Version 5.2(8a), RELEASE SOFTWARE 
ROM: 3000 Bootstrap Software (IGS-RXBOOT), Version 10.2(8a), RELEASE SOFTWARE (f 
cl) 


skynet_access_1l uptime is 1 week, 2 days, 16 hours, 19 minutes 
System restarted by reload 
System image file is "flash:/junky_old_ios.bin", booted via flash 


cisco 2511 (68030) processor (revision L) with 14332K/2048K bytes of memory. 
Processor board serial number 05309022 

Bridging software. 

X.25 software, Version 2.0, NET2, BFE and GOSIP compliant. 

1 Ethernet/IEEE 802.3 interface. 

2 Serial network interfaces. 

16 terminal lines. 

32K bytes of non-volatile configuration memory. 

16384K bytes of processor board System flash (Read ONLY) 


Configuration register is 0x2102 


skynet_access_l# 
skynet_access_l#show flash 


System flash directory: 
File Length Name/status 
1 4147048 /junky_old_ios.bin 
[4147112 bytes used, 12630104 available, 16777216 total] 
16384K bytes of processor board System flash (Read ONLY) 


skynet_access_l# 


You can see through the show version command that the router does have a version of Cisco 
10S Software later than Release 9.0—in this example, it is Release 10.3.7. Next, you check the 
amount of main memory, which, as indicated on Line 16, is 14332 K/2048 K. Overall, this 
means that the router has 16 MB of memory, divided into 14 MB of main memory and 2 MB of 
shared memory. For all practical purposes, you can view this amount as the sum of the two 
values. Next, you should check the amount of Flash memory available. This example says that 
the IOS is called junky_old_ios.bin and is approximately 4 MB in size. Because you have 16 MB 
of Flash, the router will prompt you to tell whether you want to erase the current Flash image. 
If you do not want to erase the Flash image, be sure to add the command boot system flash 
10S_ filename to the configuration. 


You now know that you can upgrade the Cisco |OS Software. You also Know the IP address and 
the name of the image. Quickly ping the TFTP server to ensure that you have IP connectivity. 
Example 1-14 walks you through the rest of upgrade process. 
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Example 1-14 Upgrading the |OS Through the TFTP Server 


skynet_access_l#ping 206.191.241.45 
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 206.191.241.45, timeout is 2 seconds: 
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms 
skynet_access_l#copy tftp flash 
KAKKK NOTICE kKKK*K 
Flash load helper v1.0 
This process will accept the copy options and then terminate 
the current system image to use the ROM based image for the copy. 
Routing functionality will not be available during that time. 
If you are logged in via telnet, this connection will terminate. 


Users with console access can see the results of the copy operation. 
aes RIA ARIE ce eee 


[There are active users logged into the system] 
Proceed? [confirmly 


System flash directory: 
File Length Name/status 
1 4147048 /junky_old_ios.bin 
[4147112 bytes used, 12630104 available, 16777216 total] 
Address or name of remote host [255.255.255.255]? 206.191.241.45 
Source file name? c2500-3s56-1.120-3.bin 
Destination file name [c2500-—js56-—1.120-3.bin]? ¢c2500-—js56-1.120-3.bin 
Accessing file 'c2500-js56-1.120-3.bin' on 206.191.241.45... 
Loading c2500-js56-1.120-3.bin from 206.191.241.45 (via Ethernet0O): ! [OK] 


Erase flash device before writing? [confirmly 
Flash contains files. Are you sure you want to erase? [confirmly 


Copy 'c2500-js56-1.120-3.bin' from server 
as 'c2500-js56-1.120-3.bin' into Flash WITH erase? [yes/no] yes 


4:23:05: SSYS-5-RELOAD: Reload requested 
SFLH: c2500-js56-1.120-3.bin from 206.191.241.45 to flash 


System flash directory: 
File Length Name/status 
1 4147048 /junky_old_ios.bin 
[4147112 bytes used, 12630104 available, 16777216 total] 
Accessing file "“c2500-—js56=-1.120-3.bin' on 206.191.241.45... 


Loading c2500-js56-1.120-3.bin .from 206.191.241.45 (via Ethernet0O): ! [OK] 
Erasing device... eeeeeeeeeeeeceeeeeceececeeecececeeeeeceececeeeeeececeeceeeeeeeeece 
ee ...erased 


Loading c2500-js56-1.120-3.bin from 206.191.241.45 (via EthernetO): !!i'rrryrrrl 
<text omitted> 
tt 


[OK — 10307412/16777216 bytes] 


Verifying checksum... OK (0xA519) 

Flash copy took 0:06:04 [hh:mm:ss] 

SFLH: Re-booting system after download 
F3: 10070412+236968+1042784 at 0x3000060 
<text omitted> 


77 


00:01:46: SSYS-5-RESTART: System restarted -—-— 

Cisco Internetwork Operating System Software 

IOS (tm) 2500 Software (C2500-JS56-L), Version 12.0(3), RELEASE SOFTWARE (fcl) 
Copyright (c) 1986-1999 by cisco Systems, Inc. 

Compiled Mon 08-Feb-99 22:55 by phanguye 

skynet_access_1> 


Also notice in Example 1-14 that the router will verify the new |OS one last time before first 
erasing the existing Flash and reloading the router. By watching the router reload, you can see 
that the new Cisco |OS Software has been loaded. This can also be confirmed by performing 
the show flash command. 


Some common problems that occur during an |OS upgrade are as follows: 


e Misspelling the 1|OS name. A common mistake is mixing up the J and L letters. 

e Having a TFTP server that is not local to the router. Make sure that the TFTP server is 
adjacent to the router. Remember that the router will reload, and a routing table will not 
be available during the ROM monitor copy phase. 

e Not verifying the proper amount of Flash or main memory needed to support the new 
108: 

e If routing is not available, use the global command IP default- gateway to direct the 
router toward a default gateway. 


NOTE 


When naming an 1OS on a router, always use the name as provided by Cisco. The 
naming convention used by Cisco correlates the filename to the feature set of the 
software. 


Configuring and Using the Access Server 


The access server provides out-of-band configuration to several devices at a single time. At a 
large site where several key routers and switches are located, an access server provides the 

best method for configuration access. You use the access server to configure the routers and 
switches in the upcoming lab. 


The configuration of the access server requires a logical tie between an IP address and a TTY 
session. To configure what Cisco refers to as reverse Telnet, you need to configure three things: 


e A transport statement 
e A loopback address 
e A host table 


Configuring the transport statement requires knowledge of what | refer to as "line entries" and 
what Cisco calls the absolute line number. To list the lines available for configuration on the 
router perform, use the show line command from the console mode. In Example 1-15, you 


can observe the absolute line number as the number on the far left under the TTY column. 


Example 1-15 Identifying Line Entries of a Router, the show line 
Command 
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Router>show line 


Tey Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int 
~ 0 CTY = - - - - @) 1 0/0 7 
1 TTY 9600/9600 —- = = = = 0 0 0/0 7 

2 TLY 9600/9600 - = = = = 0 0) 0/0 - 

2 RLY 9600/9600 —- - = 7 7 0 1 0/0 7 

4 TTY 9600/9600 - = = = = 0) 0) 0/0 - 

Se iLy 9600/9600 - = = = = 0) 0 0/0 - 

6 TTY 9600/9600 —- = - - = 0 0 0/0 i 

7 FLY 9600/9600 —- = = = = 0 0) 0/0 - 

S Try 9600/9600 —- - = = = 0 0 0/0 - 

9 TLY 9600/9600 - = = = = 0) 0 0/0 - 
LO. LLY 9600/9600 - = = = = 0) 0 0/0 ' 
da: “TTY 9600/9600 - = = - = 0 0 0/0 i 
12 TrY 9600/9600 - = = = = 0 0 0/0 = 
ls med a ag 9600/9600 - - = = = 0 0 0/0 - 
14 TTY 9600/9600 —- = = = = 0) 0 0/0 - 
15 TLY 9600/9600 —- = = = = 0) 0 0/0 = 
16 TTY 9600/9600 - = = 7 7 @) i 0/0 = 
17 AUX 9600/9600 —- = = = = 0) 0 0/0 - 
18 VTY - - - - - @) 0 0/0 - 
gO! NETL. - - - - - 0 0 0/0 - 
20 VTY 7 = = - = 0 0 0/0 = 
21 VIY = - a - - 0 0) 0/0 = 
22 VTY - = = = = 0) 0 0/0 = 

Router> 


Table 1-12 explains the line numbers and the numbering schemes found in Example 1-15. 


Table 1-12. Line Types and Number Schemes 


|Line Type | Port Type | Description | Numbering Scheme 


CON or Goneole Used for configuration Line O 
CTY purposes. 


AUX RS-232 DTE port used as_ |Last TTY line number 
a backup async port plus 1 

TTY Same as an Varies between 
asynchronous interface. platforms 
Used typically for remote- 
node dial-in sessions that 
use protocols such as 
SLIP, PPP, and Xremote. 

VTY Used for incoming Telnet, |Last TTY line number 


LAT, X.25 PAD, and 
protocol translation 
connections onto 

synchronous ports. 


plus 2, through the 
maximum number of 
VTY lines configured 
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In Example 1-15, you see that Lines 1 through 16 are TTY lines. You use these lines for the 
reverse Telnet sessions. To configure a reverse Telnet session, simply add a 20 in front of the 
absolute line number. The syntax is in one of the following two forms. From the console mode, 
it is Telnet ip_ address 20xx, where xx is the absolute line number (in this case, 01 through 
16). Be sure to include the leading 0 on single-digit numerals. The next way to configure 
reverse Telnet is entered from configuration mode, in the form of an IP host table. From the 
configuration mode, use IP host hostname 20xx ip address. The |P address used should be 
one on a loopback interface. This way, you can still use a reverse Telnet session while other 
physical interfaces are down. The IP address used needs to be reachable, which is another 
reason to use a loopback address. 


TIP 


When configuring loopback interfaces, | like to use a methodology that is logical to 
the network or model that | am building. For example, on every router, | like to 
use a Loopback 0, with an address of 201.201.x.x. | use Loopback O as the router 
ID on all the routers, where x.x is a unique number in the entire network or 
model. | chose the 201.201 portion of the address because | wanted a high 
address on Loopback 0 to force this to be a router ID for OSPF. Looking through an 
OSPF database can be quite a bit easier with logical identifiable router |Ds. | am 
also careful not to redistribute these addresses into any routing protocols. For 
protocols such as DLSw and BGP, you will use routable |P addresses on the 
loopback interfaces. | like to start these loopback interfaces at Loopback 20 and 
above. The more "self-documenting" the network or model is, the easier it will be 
to troubleshoot and maintain. Another good IP address range to use is 
192.168.00, because it is a private address, as defined in RFC 1918. 


In the following example, assume that a loopback interface has been configured with the IP 
address of 201.201.1.1. The other importance of knowing the proper line entry is to add the 
transport input all command to it. This entry allows the Telnet session to occur through the 
TTY port. You can modify the line entries one at a time, as in Example 1-16, or you can 
configure multiple lines at a time by entering the range. To enter a range, key in line x-y, 
where x is the start of the line entries and y is the end of them. 


Example 1-16 Configuration of a Reverse Telnet Session 


Router#conft t 

Enter configuration commands, one per line. End with CNTL/Z. 
Router (config) #ip host rl 2001 201.201.1.1 

Router (config) #line 1 

Router (config-line) #transport input all 

Router (config-line) #no exec 

Router (config-line) #*Z 

Router# 


Example 1-16 also makes use of the no exec command entered under the line. This is optional 
in a reverse Telnet configuration. Adding this command lessens the likelihood of contention 
over the asynchronous port. An executive process, or exec, exists on all lines. These two 
process buffer data to each other and, at times, can make it difficult to use a reverse Telnet 
session. The error message % Connection refused by remote host is an indication of this 
type of contention for the line. To clear the line of this contention or any users, enter the 
command clear line line_entry. Example 1-17 shows the common error % Connection 
refused by remote host and then shows the effect of clearing the line of this condition to 
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enter r1 successfully. 


Example 1-17 Clearing a Line 


Router#r1 
Trying +l (201.201.141.414, 2001)... 


[o} 


% Connection refused by remote host 


Router#clear line 1 

[confirm]y [OK] 

Router#r1 

Trying Yl (201.201.1141, - 2001)... Open 


R1> 


Upon successful completion of a reverse Telnet or any Telnet session, you might want to get 
back to the original starting point or the origination point. Cisco refers to this as suspending a 
session. To accomplish this, use the escape character. To enter the default escape character, 
press Ctrl-Shift-6 at the same time, and then let up and press the X key by itself. This will 
take you back to the origination point. 


To re-establish the connection, enter a show session command to find the connection number 
that you want to restore, and then key in that connection number. Example 1-18 illustrates the 
output of the show sessions command. 


Example 1-18 show sessions Command 


Router#show sessions 


Conn Host Address Byte Idle Conn Name 
dl 2 201.201.) i 0) 3 ee 

“= 2 rl 201.201 21.2 0 O21 
3: 23 201. 20 Is. Tec 0 3 3 


The number that appears on the far left is called the relative line number. For example, to 
return to the session on host r3, key in 3; to resume the session on r2, key in 1 and press the 
Enter key. The * character in front of host r1 indicates the last session that was active. To 
return to this session, simply press Return or Enter. 


The following process makes jumping past the origination point possible: 
1. Origination point (the first Cisco router Telnetted to or consoled to) 
2. First Telnet or reverse Telnet session from 1 
3. First session from 2 
4. Second session from 2 
5. Third session from 2 


At some time, you might Telnet from your origination point to another router, perhaps the 
access server. Then, from that router or access server, you might want to do a reverse Telnet 
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to all the routers in the model. In this scenario, it would be highly desirable to jump back to the 
access server while avoiding to have to go all the way back to the origination point. To 
accomplish this, press Ctrl-Shift-6 twice fast, followed by the X key. This takes you from point 
4 to point 2, as listed in the previous process without first going to the origination point. The 
rule is one (Ctrl-Shift-6) to take you back to the origination point; the second one moves you 
one into the loop, and so on. 


Configuring a Frame Relay Switch 


Conceivably, the most useful device inside and outside the lab might be the Frame Relay 
switch. Much like the jump register, the configuration of a Frame Relay switch seems to be one 
of those untold secrets of router configuration. When | learned how to configure Frame Relay 
switching, | was able to model many network installations. Because | was the "service 
provider," | could assign my own DLCls, matching those exactly as AT&T or MCI might provide. 
By accurately modeling the network in the lab, you increase your confidence level of the 
installation, along with lowering the probability of misconfiguration or the chance of sending out 
bad equipment. This section focuses on configuring the Cisco router as a Frame Relay switch. 
Further Frame Relay configuration details are covered in Chapter 5, "WAN Protocols and 
Technologies: Frame Relay." 


Essentially, Frame Relay switching is a means of switching frames based upon the data-link 
connection identifier (DLCI). In the router's Frame Relay ARP table, a DLC! number is 
associated with an interface. Frame Relay uses its ARP table to examine DLClIs and interface 
pairings to make its decisions on whether to forward a frame out a specific interface. 


The Frame Relay switch is predominately a DCE device, which means two things: 


e Any modeling requires a minimum of three routers: one router for the switch and two 
routers to use the switch to communicate with each other. 
e DCE cables are needed on the frame switch's serial interfaces. 


At this point, it is important to define some common Frame Relay terms: 


e Permanent virtual circuit (PVC)— The logical end-to-end circuit used for frame 
transport. A PVC's endpoints are addressed with DLCls. 


e Data-link connection identifier (DLCI)— A logical number between 16 and 1007 
used to identify the PVC between the customer premises equipment (CPE) and the 
Frame Relay switch. In most cases, the DLCI is only locally significant, which implies 
that only the local devices know what the DLCI numbers are. It is possible to have two 
PVCs with the same DLCI number on the remote ends referring to the same central site. 


e Local Management Interface (LMI )— Best defined as the signaling standard used 
between the router and the Frame Relay switch. LMI is used by the switch to learn 
which DLCls are defined and their status. LMI also supports a 10-second keepalive 
mechanism that verifies that the PVC is active and that data is being exchanged. Three 
types of LMI are supported on Cisco routers: cisco, ansi, and q933a. The router will try 
an autonegotiation on all three LMI types. 


- cisco— LMI type defined by the "big three," Cisco, Digital, and Northern 
Telecom. This is the default LMI type, after autonegotiation fails. LMI status 
information is sent on DLCI 0. 


- ansi— LMI type defined by ANSI standard T1.617, commonly called Annex D. 
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This is the most common type of LMI found across all Frame Relay networks. LMI 
status information is sent on DLC! 1023. 


- q933a— LMI type defined as ITU-T Q.933, or simply Annex A. LMI status 
information is sent on DLCI 0. 


e Network-to-Network Interface (NNI)— NNI is the standard used for two switches to 
communicate. NNI is used in both Frame Relay and ATM. In ATM, it is referred to as 
network node interface. 


To configure Frame Relay switching, it is necessary to perform the following tasks: 


Step 1. Enable Frame Relay switching. 
Step 2. Configure the interface LMI and Frame Relay interface type. 


Step 3. Configure PVCs, with the frame-relay route command. 


In this first example, you configure a Frame Relay switch with two end devices or routers. It is 
always good to make a PVC diagram of your model before you begin. On your diagram, include 
the DCE, PVC, and interface denotations. Figure 1-13 exhibits the diagram that you use for this 
example. The diagram highlights the network from a hardware and service provider 
perspective. The Frame Relay switch, in the middle, has two V.35 DCE cables to two other 
routers, Rl and R2. These two routers have V.35 DTE male cables connected to their Serial 0 
port. You configure a PVC with DLCI 101 on Serial 0 mapping to DLC! 102 on Serial 5. 


Figure 1-13. Basic Frame Relay Configuration Example 


frame_switch 
Frame Relay Switch 


n 1mi=cisco re 
. = — vs —f = v.95 —f a 
SO0-DTE $0-DCE S5-DCE SO-DTE 
DLCI-101 DLCI|-102 


The first step in configuring the Frame Relay switch, excluding drawing your diagram, is to 
enable Frame Relay switching. This is done with the global configuration command frame- 
relay switching. Next, configure the serial interfaces for frame relay switching. You need to 
set the encapsulation to Frame Relay with the encapsulation frame-relay command, and you 
must set the LMI type with the frame-relay Imi-type [ansi | cisco | q993a ] command from 
the interface prompt. To continue to configure the Frame Relay interface, add the frame-relay 
intf-type dce command. Because the interface is DCE, you need to use the clock rate bps 
command. The bps values range from 1200 to 8,000,000. Finally, the frame-relay route [16- 
1007]inbound_DLCI interface outbound _serial_ interface [16-1007]outbout_DLCI command 
creates a PVC on the interface and maps it to another interface. Example 1-19 demonstrates 
the use of these commands and the basic configuration of a Frame Relay switch. 


Example 1-19 Configuring a Basic Frame Relay Switch 


frame_switch# 
frame_switch#conft t 
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Enter configuration commands, one per line. End with CNTL/Z. 
frame_switch (config) #frame-relay switching 
frame_switch (config) #interface serial 0 

frame_switch(config—-if) #encapsulation frame-relay 
frame_switch(config—-if) #frame-relay intf-type dce 
frame_switch(config—-if) #frame-relay lmi-type ansi 
frame_switch(config-if) #clock rate 56000 

frame_switch(config—-if) #frame-relay route 101 interface s5 102 
frame_switch (config—if) #exit 

frame_switch (config) # 

frame_switch (config) #interface serial 5 

frame_switch(config—-if) #encapsulation frame-relay 
frame_switch(config—-if) #frame-relay intf-type dce 
frame_switch(config-if) #clock rate 56000 
frame_switch(config—-if) #frame-relay route 102 interface sO 101 
frame_switch (config—if) #exit 

frame_switch (config) # 


Example 1-20 lists the router's configuration in its entirety. 


Example 1-20 Displaying the Entire Frame Relay Configuration 


hostname frame_switch 

! 

frame-relay switching 

! 

interface Ethernet0O 

ip address 172.16.1.2 255.255.255:..0 
! 

interface Serial0 

no ip address 
encapsulation frame-relay 
clockrate 56000 
frame-relay lmi-type ansi 
frame-relay intf-type dce 
frame-relay route 101 interface Serial5 102 
! 

<<<text omitted>>> 

! 

interface Serial5 

no ip address 
encapsulation frame-relay 
clockrate 56000 
frame-relay intf-type dce 
frame-relay route 102 interface SerialO 101 
! 

<<<text omitted>>> 

! 

no ip classless 

! 

line con 0 

line aux 0 

line vty 0 4 

Login 

! 


end 


frame_switch# 


At this point, you need to verify that the switch is working. The primary things to look for are 
an establishment of a PVC and evidence that a PVC is active, with two different DLC] numbers. 
A PVC becomes active only when the LMI is being exchanged with both DTE devices. 


The "Big show" and "Big D" for Frame Relay Switching 


| call the following commands the "Big show" and the "Big D," for a couple of reasons. Yes, 
there are many other useful commands, but when it comes to debugs, fewer is better. | have a 
friend who was a systems programmer at McDonnell Douglas at the time, and he used to say, 
"If you're not breaking anything, you're not working." You can easily prove Tom's theory right 
by "working" with debug commands in a production environment. As | am sure you have been 
told, they can be output-intensive. All debug commands should be used in conjunction with the 
configuration mode key-in logging buffered 10000. The second reason that | call these the 
"big" commands is that there exists a limited set of commands and debugs that can be applied 
to resolve about 90 percent of most connectivity and routing issues. These "big" commands are 
the ones that | want to concentrate on. 


The key show commands, or the "big show," as | like to call them, for Frame Relay switching 
are as follows: 


e show interface xx— Displays the status of the physical link. The serial is up/ down 
stands for Layer 1, or the physical layer. The line protocol is up/ down stands for the 
Layer 2 protocol. Both lines should read up. Serialx is up, line protocol is down is a 
good indication of an LMI mismatch. 


e show frame-relay pvc— Displays the status of the PVCs. The PVC should be ACTIVE, 
and input/output packets should be incrementing. The DLCI usage should be 
SWITCHING not local for Frame Relay switching. 


e show frame-relay Imi— Displays the status of LMI updates sent and received. The 
Num Status Enq. Sent field should increment with the Num Status msgs Rcvd field. 
The Num Status Timeouts field should not be incrementing. The timeout message 
incrementing is a good indication of a LMI type mismatch. 


e show frame-relay route— Only valid on Frame Relay switching, shows PVC mapping 
to interface and DLCI number. Ensure that the PVC is configured correctly with the 
appropriate DLCls terminating on the appropriate interfaces. The status should be 
active. 


e debug frame-relay Imi— Displays LMI keepalive and exchange information. On an 
inbound LMI frame, a Type 1 means that the frame is normal, whereas a Type 0 is an 
LMI full status request. The output also notes LMI errors/timeouts and the link status. If 
there is an invalid LMI type code sent, the code is as follows: 


[ nvalid LMI type 1 [Cisco 
[ nvalid LMI type 2 [Annex A or Q993a 
[ nvalid LMI type 3 [Annex D or ANSI 


Still using this example, let's examine each one of these commands in more detail. From the 
Frame Relay switch, you perform a show interface command, as shown in Example 1-21. 
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Notice that Layer 1 is up, but also notice that the line protocol is down and that the line DCE 
LMI down appears. This, in combination with all the DCD=up DSR=up DTR=up RTS=up 
CTS=up verifies that Layer 1 is up and should immediately point us to a frame problem at 
Layer 2. 


Example 1-21 Example of show interface Command 


frame_switch#show interface serial 0 
Serial0O is up, line protocol is down 
Hardware is HD64570 
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255 
Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec) 
LMI eng sent 0, LMI stat recvd 0, LMI upd recvd 0 
LMI eng recvd 297, LMI stat sent 297, LMI upd sent 0, DCE LMI down 
LMI DLCI 0 LMI type is ANSI Annex D frame relay DCE 
FR SVC disabled, LAPF state down 
Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0 
Last input 00:00:05, output 01:24:05, output hang never 
Last clearing of "show interface" counters never 
Input queue: 0/75/0 (size/max/drops); Total output drops: 0 
Queueing strategy: weighted fair 
Output queue: 0/1000/64/0 (size/max total/threshold/drops) 
Conversations 0/1/256 (active/max active/max total) 
Reserved Conversations 0/0 (allocated/max allocated) 
5 minute input rate 0 bits/sec, 0 packets/sec 
5 minute output rate 0 bits/sec, 0 packets/sec 
2229 packets input, 30711 bytes, O no buffer 
Received 82 broadcasts, 0 runts, O giants, O throttles 
0 input errors, O CRC, O frame, O overrun, O ignored, 0 abort 
297 packets output, 4413 bytes, O underruns 
O output errors, 0 collisions, 645 interface resets 
0 output buffer failures, 0 output buffers swapped out 
1290 carrier transitions 
DCD=up DSR=up DTR=up RTS=up CTS=up 
frame_switch# 


Focusing more on the frame-related problems, you perform a show frame-relay pvc in 
Example 1-22. Here you are looking for PVC STATUS = ACTIVE. The DLC! USAGE will equal 
SWITCHED on the frame switch and LOCAL on the DTE side of the network. Any DLCI 
configured on this link will show up. Having a PVC register INACTIVE does not necessarily 
mean that a successful LMI status request was received. 


Example 1-22 The show frame-relay pvc Command 


frame_switch#show frame-relay pvc 
PVC Statistics for interface SerialO (Frame Relay DCE) 


DLCI = 101, DLCI USAGE = SWITCHED, PVC STATUS = ACTIVE, INTERFACE = Serial0O 


input pkts 0 output pkts. 0 in bytes 0 

out bytes 0 dropped pkts 0 in FECN pkts 0 
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 
in DE pkts 0 out DE pkts 0 

out bcast pkts 0 out bcast bytes 0 


pve create time 07:01:22, last time pvc status changed 06:59:57 
Num Pkts Switched 0 
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PVC Statistics for interface Serial5 (Frame Relay DCE) 


DLCI = 102, DLCI USAGE = SWITCHED, PVC STATUS = INACTIVE, INTERFACE = Serial5 


Input pkres 0 output pkts 0 in bytes 0 

out bytes 0 dropped pkts 0 in FECN pkts 0 
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 
in DE pkts 0 out DE pkts 0 

out. beast pkts 0 out bcast bytes 0 


pve create time 07:01:22, last time pvc status changed 02:12:10 
Num Pkts Switched 0 
frame_switch# 


Narrowing the problem even further, you perform the show frame-relay Imi command. In 
Example 1-23, you are focusing on LMI timeouts over a period of time. As mentioned 
previously, Num Status Eng Rcvd should increment with Num Status msgs Sent. Num St 
Eng. Timeouts should not increment. LMI type is denoted here. Of course, Invalids also should 
not increment. 


Example 1-23 The show frame-relay Imi Command 


frame_switch#show frame-relay lmi 


LMI Statistics for interface SerialO (Frame Relay DCE) LMI TYPE = ANSI 


Invalid Unnumbered info 0 Invalid Prot Disc 0 
Invalid dummy Call Ref 0 Invalid Msg Type 0 
Invalid Status Message 0 Invalid Lock Shift 0 
Invalid Information ID 0 Invalid Report IE Len 0 
Invalid Report Request 0 Invalid Keep IE Len 0 

Num Status Enq. Revd 297 Num Status msgs Sent 297 
Num Update Status Sent 0 Num St Enq. Timeouts 1677 


LMI Statistics for interface Serial5 (Frame Relay DCE) LMI TYPE = CISCO 


Invalid Unnumbered info 0 Invalid Prot Disc 0 
Invalid dummy Call Ref 0 Invalid Msg Type 0 
Invalid Status Message 0 Invalid Lock Shift 0 
Invalid Information ID 0 Invalid Report IE Len 0 
Invalid Report Request 0 Invalid Keep IE Len 0 

Num Status Eng. Rcvd 2806 Num Status msgs Sent 2806 
Num Update Status Sent 0 Num St Enq. Timeouts 4 


frame_switch#show frame-relay lmi 


LMI Statistics for interface SerialO (Frame Relay DCE) LMI TYPE = ANSI 


Invalid Unnumbered info 0 Invalid Prot Disc 0 
Invalid dummy Call Ref 0 Invalid Msg Type 0 
Invalid Status Message 0 Invalid Lock Shift 0 
Invalid Information ID 0 Invalid Report IE Len 0 
Invalid Report Request 0 Invalid Keep IE Len 0 

Num Status Enq. Revd 297 Num Status msgs Sent 297 
Num Update Status Sent 0 Num St Enq. Timeouts 1678 


LMI Statistics for interface Serial5 (Frame Relay DCE) LMI TYPE = CISCO 
Invalid Unnumbered info 0 Invalid Prot. Dise 0 
Invalid dummy Call Ref Invalid Msg Type 0 
Invalid Status Message Invalid Lock Shift 0 
Invalid Information ID Invalid Report IE Len 0 
Invalid Report Request Invalid Keep IE Len 0 


OS. Or" 
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Num Status Enq. Revd 2807 Num Status msgs Sent 2807 
Num Update Status Sent 0 Num St Enq. Timeouts 4 
frame_switch# 


If you performed this command over a period of time, the timeouts would keep incrementing 
and no status messages would be received. In this example, it is now becoming clear that you 
have an LMI problem. You can confirm this with the debug commands. debug frame-relay Imi 
provides useful information. By examining the log, you find the following entry noted in 
Example 1-24. 


Example 1-24 Output from the debug frame-relay Imi Command 


06:01:52: Serial5(in): StEnq, myseq 122 

06:01:52: RI IE 1, length 1, type 1 

06:01:52: KA IE 3, length 2, yourseq 123, myseq 122 

06:01:52: Serial5 (out): Status, myseq 123, yourseen 123, DCE up 
06:01:53: Serial0: Invalid LMI type 1 

06:01:58: Serial0 (down): DCE LMI timeout 


This log further confirms an LMI problem with Serial 0. An invalid LMI type of 1 indicates that 
the switch is receiving Cisco LMI from the DTE end, thereby causing the timeout and the 
"down" condition. If there were an invalid LMI type 2 or an invalid LMI type 3, the LMI 
would be Q993a or ANSI, respectively. This type field should not be confused with the type field 
received during normal operation. The type message during normal operation indicates what 
type of LMI frame is being received. In normal operation, the myseq and the yourseen fields 
would be incrementing, along with the DCE up indication, as seen with Serial 5. You now can 
be positive that an LMI problem exists. Changing the LMI type to cisco on the Frame Relay 
switch, you can observe the results in the log, as seen in Example 1-25. 


Example 1-25 The debug Output Listed in the Log File During an LMI 
Correction 


09:52:33: Serial0: Invalid LMI type 1 

09:52:39: SSYS-5-CONFIG_I: Configured from console by console 
09:52:42: Serial5(in): StEng, mysegq 232 

09:52:42: RT IE 1, length 1, type 1 

09:52:42: KA IE 3, length 2, yourseq 233, myseq 232 

09:52:42: Serial5 (out): Status, myseq 233, yourseen 233, DCE up 
09:52:43: Serial0 (down): DCE LMI timeout 

09:52:43: SerialO(in): StEng, myseq 0 

09:52:43: RT IE 1, length 1, type 0 

09:52:43: KA IE 3, length 2, yourseq 6 , mysegq 0 

09:52:43: SerialO (out): Status, myseq 1, yourseen 6, DCE down 
09:52:52: Serial5(in): StEng, mysegq 233 

09:52:52: RI IE 1, length 1, type 1 

09:52:52: KA IE 3, length 2, yourseq 234, myseq 233 

09:52:52: Serial5(out): Status, myseq 234, yourseen 234, DCE up 
09:52:53: Serial0O(in): StEnq, myseg 1 

09:52:53: RT IE 1, length 1, type 1 

09:52:53: KA IE 3, length 2, yourseq 7 , mysegq 1 

09:52:53: SerialO (out): Status, myseq 2, yourseen 7, DCE up 
09:52:53: SLINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state 
EO wp 

09:53:00: SFR-5-DLCICHANGE: Interface Serial5 - DLCI 102 state changed to ACTIVE 


~ nN nN 


09:53:02: Serial5(in): StEnq, myseq 234 
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09:53:02: RI IE 1, Length 1, type 1 

09:53:02: KA IE 3, length 2, yourseq 235, myseq 234 

09:53:02: Serial5 (out): Status, myseq 235, yourseen 235, DCE up 
09:53:03: Serial0O(in): StEnq, mysegq 2 

09:53:03: RT IE 1, length 1, type 1 

09:53:03: KA IE 3, length 2, yourseq 8 , mysegq 2 

09:53:03: Serial0O (out): Status, myseq 3, yourseen 8, DCE up 


At this time, you should have a basic understanding of the configuration required to model a 
Frame Relay switch. The lab exercise addresses subtle changes needed to make this a 
multipoint Frame Relay connection. We discuss more about Frame Relay LMI frames and their 
exchange in Chapter 5. 


Configuring a Route Generator or Backbone Router 


The next component that is helpful in modeling the internetwork is the route generator, or 
backbone router. A route generator is simply a router configured with virtual networks or 
loopback interfaces. These virtual networks are given a Layer 3 address and are advertised by a 
routing protocol. The main use is to make your test network look bigger than it really is, from a 
physical aspect, by injecting routes into your routing tables. To configure a route generator, 
perform the following tasks: 


Step 1. Add one or more virtual interfaces or loopbacks. 
Step 2. Decide what Layer 3 protocols to use, and apply it to the loopback interfaces. 


Step 3. Advertise these networks with a routing protocol. 


Still using your small frame network, you will configure one router to be a route generator, and 
then you will examine how the route generator looks to a downstream neighbor. To configure a 
loopback interface, enter interface loopback [0-2147483647] from configuration mode. You 
then must add a Layer 3 address and decide how to advertise the networks. Example 1-26 adds 
several loopback address with IP addresses. Using EIGRP with an autonomous system ID of 
2001, you advertise these networks across the Frame Relay cloud to another router. With 
Figure 1-14 as your map, you can configure R1 as a route generator. 


Figure 1-14. Route Generator, |P Map 


IP address map 


Router 2 
(R2) 


p.ci-102— fg 


S0-IP-172.16.17 2/24 


Router 1 


ae ao 


$0-IP-172.16.17.1/24 


Loopback 20-/P-172.16.1. 1/24 
Loopback 21-/P-172. 16.2. 1/24 
Loopback 22-(P-172. 16.3. 24 
Loopback 23-/P-172. 16.4. 1/24 
Loopback 24-/P-172. 16.5. 1/24 


Frame Relay 
provider 
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Example 1-26 shows the configuration for R1. 


Example 1-26 Configuring a Route Generator 


rl#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 

rl (config) #interface loopback 20 

rl (config-if) # 

02:41:51: SLINK-3-UPDOWN: Interface Loopback20, changed state to up 

02:41:52: SLINEPROTO-5-UPDOWN: Line protocol on Interface Loopback20, changed st 
ate to up 

rl (config-if)#ip address 172.16.1.1 255.255.255.0 
rl (config-if)#interface loopback 21 

rl (config-if)#ip address 172.16.2.1 255.255.255.0 

rl (config-if)#interface loopback 22 

rl (config-if)#ip address 172.16.3.1 255.255.255.0 

rl (config-if) #interface loopback 23 

rl (config-if)#ip address 172.16.4.1 255.255.255.0 

rl (config-if)#interface loopback 24 

rl (config-if)#ip address 172.16.5.1 255.255.255.0 

rl (config-if) #exit 

rl (config) #router eigrp 2001 

rl (config-router) #network 172.16.0.0 

rl (config-router) #exit 

rl (config) #interface serial 0 

rl (config-if)#ip address 172.16.128.1 255.255.255.252 
rl (config-if) #*Z 

vl# 


bh 


After configuring R2 for IP and adding EIGRP, you can observe how the virtual networks appear 
to a downstream router. In later chapters, you use route generators to practice filters and 
observe how routes are handled by the different routing protocols. Example 1-27 lists the 
routing table of R2, after the router was configured with the appropriate IP address on the 
serial interface and a routing protocol. 


Example 1-27 Route Generator Advertising Networks to a Downstream 
Router 


cr2# 
r2#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M —- mobile, B — BGP 
D —- EIGRP, EX — EIGRP external, O — OSPF, IA — OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U - per-user static route, o -— ODR 
T - traffic engineered route 


Gateway of last resort is not set 


172.16.0.0/16 is variably subnetted, 6 subnets, 2 masks 
172.16.128.0/30 is directly connected, Serial0O 
172.16.4.0/24 [90/2297856] via 172.16.128.1, 00:11:09, SerialOd 
172.16.5.0/24 [90/2297856] via 172.16.128.1, 00:11:09, SerialO 
172.16.1.0/24 [90/2297856] via 172.16.128.1, 00:11:09, SerialO 
172.16.2.0/24 [90/2297856] via 172.16.128.1, 00:11:09, SerialOd 
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D 172.16.3.0/24 [90/2297856] via 172.106.1281, 00411+09, Serialo 
c2# 


Notice that R2 has EIGRP D routes reported from 172.16.128.1. This router now appears to be 
part of a much larger EIGRP network. 


Configuring Analog Remote Access 


Remote access to a network can be considerably useful during your studies and in the field. The 
Cisco TAC often asks if an analog modem is attached, to help in troubleshooting your problem. 
Problem solving can be significantly easier when another person can get a firsthand view of the 
problem. Being able to troubleshoot from a remote location with this type of an out-of-band 
connection alone can be invaluable. The sections presented here are intended to arm you with 
enough knowledge to configure a simple analog modem for remote support or for PPP backup. 
Cisco Systems and Cisco Press have an excellent 1,500- page reference entitled Cisco |OS Dial 
Solutions that covers dialup networks extensively. Most of the information offered in the 
following section is a derivative of the information presented in that text. 


Configuring analog remote access can be abstract at times. A close association exists between 
the Cisco I|OS level, the router port, and the modem, making it difficult to port configurations 
from one router type to another. Most often, any change in the router platform or switching 
modem types force you to reconfigure the router. However difficult it might be to configure or 
reconfigure at times, learning a few commands can get you through a majority of analog dialup 
issues. 


This section focuses on terminal sessions connecting to the routers through their auxiliary or 
the asynchronous ports on the access server. Chapter 4, "WAN Protocols and Technologies: 


Point-to-Point Protocol (PPP)," covers PPP and how it is used in conjunction with the AUX, 
asynchronous (async), and serial ports. 


Let's compare the asynchronous interface on the router to the auxiliary port. Both interfaces 
are capable of all asynchronous functions, which include the following: 


e Network protocol support (such as IP, IPX, or AppleTalk) 
e Encapsulation support (such as PPP and ARA) 
e Authentication support 


One of the noticeable differences between the AUX and the async port is the speed at which 
they can operate. The maximum speed for an asynchronous interface is 115,200 bps, whereas 
the AUX port operates at a maximum speed of 38,400 bps. Table 1-13 outlines this and other 
differences between the AUX and async ports. 


Table 1-13. AUX and Asynchronous Comparison 


Asynchronous ee | 
Enchantments/ Features Interface ee | 


Maximum speed = 15,200 bps ~ ,400 bps 


Offers DMA buffering for direct 
memory access without CPU 
interruption 


the interface, which removes 


additional overhead from the CPU 


With these differences aside, the two ports operate and are configured almost identically. 


In configuring analog, access is necessary to configure the modem. Modem configuration can 
vary from modem to modem; however, most of the modems today have standardized the AT 
commands sets that they use. The AT command set is a way to Set bit registers in the modem 
with key-ins or strings that you send to the modem. AT commands allow you to force 
compression, answer the phone on one ring, and so on. To configure the router to support 
modems, you need to perform the following three tasks: 


Step 1. Attach the modem to the AUX or asynchronous ports. 
Step 2. Configure the modem lines or the line entries. 


Step 3. Configure the modem by chat scripts or automatically. 
Step 1: Attaching the Modem to the AUX or Asynchronous Ports 


The first step in configuring analog communications is to attach the modem to the router. Table 
1-14 repeats Table 1-2 from earlier in the chapter so that you can verify what type of cable and 


what type of head-shell to use on the modem. Most cases involve attaching the Cisco black or 
blue rolled cable to the AUX port. The MMOD type head-shell is used on the modem. 


Table 1-14. Asynchronous Device Cabling Options from Earlier 


Access Server RJ -45 Console Head- Shell End 
Port Cable Type Adapter Device 
Console or aux Rolled DTE pinout Serial 
cable 
Console or aux Straight DCE pinout Serial 
cable 


Console or aux [MMOD/MODEM Modem 


Step 2: Configure the Modem Lines or the Line Entries 


The next step is to configure the line commands that correspond to the AUX or the 
asynchronous line. To find the corresponding line entry, perform the show line command. 
Examine the output, and record the absolute line number that the AUX port is on. Example 1- 
28 lists the output for the show line command. Notice that the absolute line number in this 


example is 1. To begin to configure the AUX port for asynchronous communications, you need 
to enter the Line 1 statement from the configuration mode. 


Example 1-28 Output for the show line Command 
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Router#show line 


Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int 

ae JO) CIE = = = = = 0 i 0/0 = 

1 AUX 9600/9600 —- = = = = 0 L 0/0 = 

2 VEY = = = = = 0) 0 0/0 = 

3 VTY - a = = = 0 0 0/0 - 

4 vTY = = = = = 0 0 0/0 = 

5S VTY - - = = = 0 0 0/0 - 

6 VTY = = = = = 0 0 0/0 - 
Router# 


If you perform the same show line command on your access server, the output is a little more 
complicated. In Example 1-29, the absolute line number for the AUX port is 17. Therefore, if 
you want to add a modem to this AUX port, you need to begin your configuration with the 
statement Line 17 from configuration mode. 


Example 1-29 The show line Command Performed on the Access Server 


skynet_access_l#show line 


Tey Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int 
a Oe CY = = = = = 1 0 0/0 as 
1 TTY 9600/9600 - = = = = 0 0 0/0 = 

2 TTY 9600/9600 —- = = = = 0 103 0/0 = 
eS TY 9600/9600 —- = = = = 0 1 1400/4202 = 
* 4 TTY 9600/9600 —- = = = 0 0 1401/4203 = 
x 5. LEY 9600/9600 - = = = if 1 2/9 = 
* 6 TEY 9600/9600 —- = = = 0 0 465/1704 = 
7 TLy 9600/9600 —- = = = = 0 0 0/0 = 

8 TTY 9600/9600 - = = = = 0) 0 0/0 = 

OS TLY 9600/9600 - = = = = 0 0 0/0 = 

LO LEY 9600/9600 - = = = = 0 0 0/0 < 
14. TLyY 9600/9600 - = = = = 0 0 0/0 = 
12 TIrY 9600/9600 - = = = a 0 0 0/0 = 
13. TITY 9600/9600 - = = = = 0) 0 0/0 = 
14 TTY 9600/9600 - = = = = 0 0 0/0 = 
15. TTY 9600/9600 - = = = = 0 0 0/0 = 

* 16 TTY 38400/38400 — inout = = = 0 0 0/0 = 
17 AUX 9600/9600 —- = = = = 0 0 0/0 = 
18 VTY = = = = = 0 0 0/0 = 
Lo: VIY = = = = = 0) 0 0/0 = 
20 VIX = = = = = 0 0 0/0 a 
21. VEY = = = = = 0 0 0/0 = 
Tty Typ Tx/ RX A Modem Roty AccO AccI Uses Noise Overruns Int 
22 VIY¥ = = = = = 0) 0 0/0 = 


skynet_access_1# 


When you identify the appropriate line entry to modify, you can configure the line to support a 
modem. The characteristics that you want to configure at this point apply to Layer 1. That is 
the speed at which the router communicates with the modem, how the modem handles flow 
control, and how it handles the carrier. 


Addressing speed first, it is important to note that the port speed of the router is not the same 
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as the modem transmission rate. Comparing the two in Table 1-15, you find the following to be 
true. 


Table 1-15. Modem Transmission Rates Versus Port Speed 


Modem Transmission Port Speed as Entered Under the Line x 
Rate Interface 


[9600 [38,400 
14,400 [57,600 
28,800 115,200 


Table 1-13 noted that the maximum speed for an auxiliary port is 38,400, and the default 
modem transmission rate is 9600; therefore, you do not need to adjust the speed to get the 
maximum baud rate. To adjust the speed, in the case of using an asynchronous line, use the 
speed [38400 | 57600 | 115200] command. 


If you adjust the speed above 38,400, enable hardware flow control. This is accomplished with 
the statement flowcontrol hardware. 


The line must tell the modem also how to handle Carrier. To configure the line to hang up the 
connection when carrier detect (CD) is lost, use the modem inout statement. In some cases, 
you want the modem only to answer—the modem dialin statement would be used in this case. 


Step 3: Configure the Modem by Chat Scripts or Automatically 


The final step is to configure the modem initialization settings. The easiest and most 
straightforward method to configure external modems is with the autoconfigure command. 
Cisco |OS Software defines several initialization strings for most major modem brands. To view 
these predefined stings, enter the show modemcap command. Example 1-30 lists the output 
of the show modemcap command and the modems predefined in Cisco |OS Software Release 
12.0.3, the current |OS of the router. 


Example 1-30 The Output from the show modemcap Command 


Router#show modemcap 
default 
codex_3260 
usr_courier 
usr_sportster 
hayes_optima 
global_village 
viva 
telebit_t3000 
microcom_hdms 
microcom_server 
nec_v34 
nec_v110 
nec_piafs 
e1lsco_v1l10 

mica 
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Router# 
Router#show modemcap default 
Modemcap values for default 


Factory Defaults (FD): 6&F 

Autoanswer (AA): S0=1 

Carrier detect (CD): &Cl 

Drop with DTR (DTR): &D2 

Hardware Flowcontrol (HFL): [not set] 
Lock DTE speed (SPD): [not set] 

DTE locking speed (DTE): [not set] 
Best Error Control (BER): [not set] 
Best Compression (BCP): [not set] 

No Error Control (NER): [not set] 

No Compression (NCP): [not set] 

No Echo (NEC): EO 

No Result Codes (NRS): Q1 

Software Flowcontrol (SFL): [not set] 
Caller ID (ClpD) 3 [not set] 

On-hook (ONH): HO 

Off=hook (OFH): Hl 

Miscellaneous (MSC): [not set] 
Template entry (TPL): [not set] 


Modem entry is built-in. 


Router# 


This listing also shows the predefined AT strings for the modem type called default. Over the 
years, Cisco has made great strides in improving the robustness and ease of configuration for 
analog support. In the past, and still supported, are what Cisco refers to as chat scripts. The 
chat script is entered from the configuration mode in the format chat-script EXPECT SEND 
EXPECT SEND. You then call the chat script from the line entry. About 90 percent or more 
modems function out of the box without complicated AT command strings. Try to avoid the use 
of chat scripts whenever possible, and use the modem auto-configure discovery or modem 
auto-configure type default, if your modem is not listed in the show modemcap command. 
Yet one more way to avoid the use of complicated chat scripts is to create your own or modify 
the existing modemcap entries. This is done using modemcap edit modem-name attribute 
value in configuration mode. This command allows for easy manipulation of the AT commands 
through a streamlined interface. 


After you identify the modem type to use or have defined your own type, you make the logical 
connection by adding the modem auto-configure type modem-name, under the appropriate 
line entry. 


Configuration Walkthrough: Adding a Modem to a Router 


Example 1-31 is a complete walkthrough of the configuration needed to add a modem to a 
router. 


Step 1. Verify what line entry you need to modify. This is done with the show line 
command. Record the absolute line number, the number highlighted or to the far right 
of the display. Refer to this number as X. 


Step 2. Enter the configuration mode, and enter the appropriate line x configuration 
command. 


Step 3. Still under the line entry, add the following: 
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- transport input all 

- modem inout 

- modem autoconfigure discovery 
-or- 


- modem autoconfigure type [default | modem-name] 
Step 4. Configure an enable password, to allow privileged mode access. 


Example 1-31 Walkthrough of Configuring Analog Dial Access on an 
AUX Port 


Router# 
Router#show line 
Tey Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int 
0) CTY = = = i = 0 9 0/0 = 
1 AUX 9600/9600 - = = = = 0 1 0/0 fe 
2 VI = = = = = 0 0 0/0 = 
3 VI¥ = = = = = 0 0 0/0 = 
4 vTY = = S = = 0 0 0/0 = 
o> VEY = = = = = 0 0 0/0 = 
6 VI = = = = = 0 0 0/0 = 
Router# 


Router#conft t 

Enter configuration commands, one per line. End with CNTL/Z. 
Router (config) #line 1 

Router (config-line) #transport input all 

Router (config-line) #modem inout 

Router (config-line) #modem autoconfigure discovery 

Router (config-line) #*Z 

Router# 


After the line commands have been entered, verify modem connectivity by opening a reverse 
Telnet session to it. In Example 1-32, you add a loopback interface with the IP address of 
201.201.201.1, to support the reverse Telnet session. If the session does not open, remember 
to use the clear line command and then try the reverse Telnet again. When you are in session 
with the modem, you can reset it with the ATZ command, as shown. If you can perform a 
reverse Telnet, this means that the transport is configured properly and that the line was open. 
If you can perform a reverse Telnet but cannot perform an ATZ command, you probably have a 
cabling issue. 


If you still cannot perform the reverse Telnet session or the ATZ, ensure that you have added 
all the previous lines, and then turn on the debugs. To exit from or suspend the reverse Telnet 
session, press Ctrl-Shift-6 and then X. To continue troubleshooting the line, use the 
disconnect command to close the reverse Telnet session. 


Example 1-32 A Reverse Telnet Session, Followed by an AT Command 


Router#telnet 201.201.201.1 2001 
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Trying 201..201 201.1; 2001 2a. Open 


atz 
OK 


Router# 

Router#disconnect 

Closing connection to 201.201.201.1 [confirm]ly 
Router# 


The "Big show" and "Big D" for Modems 


Two powerful debugs are available to assist in troubleshooting modem connections. The "big 
D," or debugs, used for modems are debug modem and debug confmodem. These, used 
with the show line x command, can narrow down modem problems quickly. Using the show 
line x command, you can observe a few key indicators that this line is working well (refer to 
Example 1-33). You should see the modem status as detected. You should also see the 
modem state as idle, and you finally should see the leads. If the modem state is not idle, try to 
clear it with the clear line x command. 


Example 1-33 Example of Working Modem and the show line Command 


Router#show line 1 


Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int 
1 AUX 38400/38400 — inout = = = 0 i 0/0 - Te 
Line 1, Location: "", Type: "" 


Length: 24 lines, Width: 80 columns 

Baud rate (TX/RX) is 38400/38400, no parity, 2 stopbits, 8 databits 
Status: No Exit Banner, Modem Detected 

Capabilities: Modem Callout, Modem RI is CD, Modem Discovery 

Modem state: Idle 

Group codes: 0 

Modem hardware state: CTS* noDSR DTR RTS, Modem Configured 

Special Chars: Escape Hold Stop Start Disconnect Activation 


AR 


bd none = - none 
Timeouts: Idle EXEC Idle Session Modem Answer Session Dispatch 
VOS10300 never none not set 
Idle Session Disconnect Warning 
never 
Login-sequence User Response 
00300230 
Autoselect Initial Wait 
not set 


Modem type is usr_sportster. 

Session limit is not set. 

Time since activation: never 

Editing is enabled. 

History is enabled, history size is 10. 
DNS resolution in show commands is enabled 
Full user help is disabled 

Allowed transports are lat pad vl20 mop telnet rlogin nasi. Preferred is lat. 
No output characters are padded 

No special data dispatching characters 
Router# 
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Example 1-34 shows an invalid line. Notice that the speed changes from listing to listing. This is 
because the router is constantly trying to communicate with the modem. Also, the status line is 
missing modem detected. Finally, note that the router cannot detect Clear to Send (CTS); this 
is a good indication of a cabling or head-shell problem. 


Example 1-34 Example of Invalid Line, with the show line Command 


Router#show line 1 


Trey Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int 
* 1 AUX 1200/1200 —- inout 7 - = 3 i 0/0 ms 
Line 1, Location: "", Type: "" 


Length: 24 lines, Width: 80 columns 
Baud rate (TX/RX) is 1200/1200, no parity, 2 stopbits, 8 databits 


Modem state: Ready 


Group codes: 0 


Special Chars: Escape Hold Stop Start Disconnect Activation 


AN 


x none = - none 
Timeouts: Idle EXEC Idle Session Modem Answer Session Dispatch 
00310: 00 never none not set 
Idle Session Disconnect Warning 
never 
Login-sequence User Response 
00300230 
Autoselect Initial Wait 
not set 


Modem type is usr_sportster. 

Session limit is not set. 

Time since activation: never 

Editing is enabled. 

History is enabled, history size is 10. 
DNS resolution in show commands is enabled 
Full user help is disabled 

Allowed transports are lat pad vl20 mop telnet rlogin nasi. Preferred is lat. 
No output characters are padded 

No special data dispatching characters 
Router# 


Turning on the two debugs mentioned in the beginning of this section, you can observe the 
router continually trying to communicate with the modem. The TTY1 session in Example 1-35 


stands for the TTY session on Line 1, which is where you have your modem attached. 


Example 1-35 Output from the debug confmodem and debug modem 


Router#debug modem 

Modem control/process activation debugging is on 
Router#debug confmodem 

Modem Configuration Database debugging is on 

Router# 

06:03:15: TTY1: autoconfigure probe started 

06:03:18: TTY1: detection speed (38400) response -—-—--—-—- 
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06:03:21: TTY1: detection speed (19200) response ------ 
06:03:24: TTY1: detection speed (9600) response —-----— 
06:03:27: TTY1: detection speed (2400) response —-----— 
06:03:30: TTY1: detection speed (1200) response ------ 
06:03:34: TTY1: detection speed (300) response -—---—-- 
06:03:34: TTY1: No modem found 

06:03:34: TTY1: autoconfigure probe started 

06:03:37: TTY1: detection speed (38400) response —----—-— 
06:03:40: TTY1: detection speed (19200) response ------ 
06:03:43: TTY1: detection speed (9600) response —-----— 
06:03:46: TTY1: detection speed (2400) response ------ 
06:03:49: TTY1: detection speed (1200) response —-----— 
06:03:53: TTY1: detection speed (300) response —----- 
06:03:53: TTY1: No modem found 

06:03:53: TTY1: autoconfigure probe started 


Fixing the cable, you now can observe a proper operating line, as in Example 1-36. The line 


Modem configuration succeeded and the presence of CTS is a clear indication that a valid 
modem has been detected. 


Example 1-36 Output from the debug confmodem and debug modem 
Continued 


06:38:21: TTY1: autoconfigure probe started 

06:38:25: TTY1: detection speed (38400) response ------ 
06:38:28: TTY1: detection speed (19200) response -—----—-— 
06:38:31: TTY1: detection speed (9600) response -—--—---— 
06:38:34: TTY1: detection speed (2400) response —-----— 
06:38:37: TTY1: detection speed (1200) response ------ 
06:38:40: TTY1: detection speed (300) response —----—- 
06:38:40: TTY1: No modem found 

06:38:40: TTY1: CTS came up on IDLE line 

06:38:40: TTY1: autoconfigure probe started 

06:38:41: TTY1: detection speed (38400) response -—--OK--—-— 
06:38:44: TTY1: Modem type is usr_sportster 

06:38:44: TTY1: Modem command: --AT&F&C1&D2&M4&K1&B1S0=1H0-- 
06:38:44: TTY1: Modem configuration succeeded 

06:38:46: TTY1: detection speed (38400) response -—--OK--—-— 
06:38:46: TTY1: Done with modem configuration 


Finally, you can observe the configuration in its entirety in Example 1-37. 


Example 1-37 A Router Configuration with a Modem Attached to I ts 
AUX Port 


hostname router 
! 
ip subnet-zero 


ip host modem 2001 201.201.201.1 
! 


interface Loopback0O 
ip address 201.201.201.1 255.255.255.0 


no ip directed-broadcast 
! 
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interface Ethernet0O 

no ip address 

no ip directed-broadcast 
shutdown 

! 

interface Serial0d 

no ip address 

no ip directed-broadcast 
no ip mroute-cache 
shutdown 

! 

interface Seriall 

no ip address 

no ip directed-broadcast 
shutdown 


! 
ip classless 
! 
line con 0 
transport input none 
line aux 0 
modem InOut 
modem autoconfigure discovery 
transport input all 
speed 38400 
line vty 0 4 
login 
! 


end 


Router# 
Configuring Microsoft Windows 95/98 Networking 


The goal of all internetworking is to reliably transfer data from one network to another. 
Therefore, no model could be called reliable if it were not properly tested with real data and 
real applications. Therefore, the last components needed to completely model the internetwork 
are test data and test applications. 


As previously mentioned, the entire Microsoft Windows OS line, Windows 95/98/2000 and NT, 
provides all the network protocols needed to test many network models. The two protocols that 
we concentrate on are TCP/IP and NetBEUI. You use TCP/IP-related applications such as Telnet, 
FTP, and TFTP to test filters, verify IP reachability, and upgrade a router with TFTP. You use 
NetBEUI to test the functionality of bridging and DLSW configurations. 


Brief Overview of Configuring TCP/IP for Windows 95/98 


In case you do not have your workstation or laptop configured for TCP/IP, this session briefly 
walks you through the process: 


Step 1. Install your network interface card (NIC), according to the manufacturer's 
instructions. This might include instructions on how to set up TCP/IP, which supplement 
this text. 
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Step 2. Click Start, Settings, Control Panel, Network. When the Network dialog box 
appears, click the Add button. 


Step 3. A menu pops up listing Client, Adapter, Protocol, and Service. From this 
selection, click Protocol. The manufacturer of the TCP/IP stack that ships with Windows 
is Microsoft, so click on that manufacturer and then select TCP/ IP. Windows prompts 
you through the setup process and then wants to reload your workstation. Avoiding 
reloads during IP configuration is one of the many improvements in Windows 2000. 


Step 4. After the workstation reloads, right-click the Network Neighborhood icon 
located on the desktop, and select Properties. 


Step 5. The Network dialog box again appears; Step 4 is simply a short cut to this 


dialog box. Under the Configuration tab, select the entry labeled TCP/IP; (your NIC 
card). Then click the Properties button. Figure 1-15 illustrates the Network dialog box. 


Figure 1-15. The Network Dialog Box 


Network - HEV 


Configuration Identification | Access Control | 


The following network components are installed: 


'@\ Client for Microsoft Networks 
| Client for Netware Networks 
# 3Com EtherLink Ill 1S (3C509b-T PO) in PnP mode 
4S IPX/SPX-compatible Pratocol 


Remove | Properties | 


Primary Network Logon: 


| Client for Microsoft Networks ¥ | 


File and Print Sharing... | 


— Description 
TCP/IP is the protocol you use to connect to the Internet and 
wide-area networks. 


WIdE-afea Nelo s. 


OK | Cancel | 


Step 6. |n the TCP/IP Properties window, click the IP Address tab at the top. Then 
click Specify an IP Address, and enter the address in the field provided. 


Step 7. For IP to work properly, you must also add a default gateway. The default 
gateway should be the IP address of a router on the same LAN segment. This router 
handles all of the workstation's requests that are not local. To configure a default 
gateway, click the Gateway tab and enter the appropriate IP address. 


Step 8. Finally, to use DNS services, click the tab DNS Configuration, and enter the 
DNS server that you want to use. Then click the Add button. 


After Steps 7 or 8, the workstation reloads. To test your configuration, click the Start button 

and choose Programs, MS-DOS Prompt. This opens a DOS session. From here, you use the 
ping command to test IP functionality. The ping command also can be run with Start, Run, 

followed by keying in ping x.x.x.x. To test DNS functionality, ping IP hosts by using the DNS 
name association instead of the actual IP address. 


Brief Overview of Configuring NetBEUI for Windows 95/98 


The other host-based protocol that you need to install is NetBEUI. Combined with enabling 
Windows file and print sharing, the NetBEUI protocol provides a great test application for DLSw 
and bridging functions. NetBEUI is a nonroutable protocol, which does not have a specific 
network layer address. To forward these protocols from one network to another, you must use 
bridging or DLSw. Click the Start button and choose Find, Computers. Key in any name, and 
click the Find button. This sends an all-routes explorer frame. The explorer frame transverses 
DLSw connections, as well as source-route bridges, transparent bridges, and translational 
bridges. It is evident that NetBEUI will be of great use in the lab. 


To configure NetBEUI, perform the following steps: 


Step 1. Right-click the Network Neighborhood icon, located on the desktop, and 
select Properties. 


Step 2. The Network dialog box appears. Click the Add button. 


Step 3. A menu pops up listing Client, Adapter, Protocol, and Service. From this 
selection, left-click Protocol. Click Microsoft as the manufacturer, and then select 
NetBEUI. Windows prompts you through the setup process, and then it will want to 
reload your workstation. 


Step 4. After the workstation reloads, right-click the Network Neighborhood icon, 
followed by the Properties button. 


Step 5. The Network dialog box appears again. Click the Identification tab at the top. 
Enter a workstation name that will appear as a DLSw identifier. 


Step 6. Finally, to establish end-to-end sessions across the model, you must enable 
Microsoft file and print sharing. Click the Add button. This time, you will be adding a 
service, so click the Service selection. 
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Step 7. The service that you need to add is Microsoft file and print sharing, so click on 
this selection. Windows will then install this feature. 


Step 8. When file and print sharing is enabled, verify it by clicking the button Microsoft 
File and Print Sharing; make sure that both boxes are checked. Then open the 
Windows Explorer. Click the drive that you would share by right-clicking the drive icon 
and selecting the Sharing selection. If the drive is not shared, click the Share box, and 
be sure to include a password. 


CAUTION 


If you are connected to a cable modem provider in your area, be careful to 
password-protect your hard drives and any shared resources. The cable modems 
work on a broadcast mechanism for local access. Therefore, everyone on your 
local cable modem segment can see your PC and any shared resources. 


You need two workstations to properly test the NetBEUI and Windows file and print sharing. To 
test the configuration, choose Start, Find. Key in the name that you entered in the 
Identification tab on Step 5. This locates the workstation. Clicking the workstation name puts 
you in a session with that workstation. Any shared resources then are displayed. Simply click 
the resource to use it from your workstation. 
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Practical Study for Chapter 1: Setting Up 


So far, this chapter discussed the key components needed for modeling the internetwork. 
Now it is time to take what you learned and apply it. Without application, it becomes hard to 
grasp and retain the concepts put forth so far. 


At the heart of practical studies lies the goal of modeling the internetwork. But before you 
begin with modeling networks and different protocols, you must prepare the lab by 
configuring the key components discussed in this chapter. As you progress deeper into 
modeling the internetwork, the labs are increasingly harder. At the end of the study are five 
complete CCIE practice labs. These labs are for your own personal challenge when preparing 
for the CCIE Lab Exam, and answers are supplied on the Cisco Press website, www.ciScopress. 


com. 


The labs are divided into two major parts, the lab exercise or scenario and then a lab 
walkthrough. First, try to perform Part | of the lab without looking at Part II, the 
walkthrough. Each lab covers the topics in that chapter, but some labs might also introduce 
new areas of study. 
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Lab 1: Password Recovery—Part | 
Practical Scenario 


You might need to perform password recovery on a router at many times. To model and set 
up your lab for practical studies, you need at least three routers. Most of the equipment has a 
high probability of being used. This equipment might require password recovery for 
privileged-level access. Sometimes, customers forget passwords. In either case, you need to 
perform password recovery. 


Lab Exercise 


You received a stack of routers that you can use to model complex networks. Because this 
equipment is used, it has an existing configuration stored on NVRAM that is password- 
protected. You are tasked to archive and then erase the current router configuration. 


Lab Objectives 


e Examine the original configuration of the router. 
e Erase the configuration. The router should have no configuration, and, when it boots, 
it should come up in setup mode. 


Equipment Needed 


e One Cisco router. 

e One Cisco configuration kit (one rolled cable and appropriate head-shell to connect to 
the PC/laptop's COM port). 

e One PC or laptop with terminal-emulation software. 

e All labs from this point on require a PC or laptop with the standard configuration kit 
and terminal-emulation software. This is the only lab in which this basic configuration 
equipment is mentioned. 


Physical Layout and Prestaging 


The router used must have some previous configuration and an enable password set. 


105 


Lab 1: Password Recovery—Part Il 


Lab Walkthrough 


As discussed previously, password recovery is similar from one router platform to another. 
Therefore, you can apply the process outlined earlier in this chapter here, with a few 
modifications to fit the lab exercise. 


The procedure outlined in the list that follows is valid for the following routers: 


Cisco 2000 series 

Cisco 2500 series 

Cisco 3000 series 

Cisco 4000 series with the 680x0 Motorola CPU 

Cisco 7000 series running Cisco |OS Software Release 10.0 or later in ROMs installed 
on the RP card 

e IGS series running Cisco |OS Software Release 9.1 or later in ROMs 


Step 1. Attach a PC or PDA with terminal-emulation software to the router's console 
port through Cisco rolled cable. 


Step 2. Power-cycle the router. 
Step 3. Issue a break signal. 


Step 4. Determine what type of ROM monitor you have—is CONREG supported? 


- If you have a Basic ROM monitor: Set bit 6: >O/ R Ox2142. Reload the 
router with the initialize command. 


- If CONFREG is supported: Run the CONFREG utility: >CONFREG. Answer 
every question with the default or Enter until you come to the question 
Enable ignore system config info. Answer "yes" to this question. This also 
sets bit 6. Reload the router with the reset command. 
Step 5. When the router reloads, it will try to run setup, abort the setup utility with 
CTRL-C. 


Step 6. Enter enable mode, and examine the configuration found in NVRAM; use the 
show startup-config command to accomplish this. 


For this walkthrough, you perform a password recovery operation to gain privileged level 
access to your access server. In this example, the access server is called skynet_access_1. 


First, attach a PC or laptop with terminal-emulation software to the console port of the 
router. Power off the router and turn it back on. Within the first 60 seconds of initialization, 
issue a break signal from your terminal emulator. Example 1-38 demonstrates a successful 


break or halt of the OS. 


Example 1-38 A Successful Break 


System Bootstrap, Version 5.2(8a), RELEASE SOFTWARE 
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Copyright (c) 1986-1995 by cisco Systems 
2500 processor with 14336 Kbytes of main memory 


Abort at Ox1l0OEA888 (PC) 
> 


Getting the terminal-emulation software to send a break signal is a common problem with 
password recovery. Here are a few tips that might help if you have trouble sending a break 
signal: 


e First, ensure that you are securely plugged into the console port of the router and 
using the Cisco rolled cable. 

e If your portable or laptop computer is using Windows 95/98/2000 with 
HyperTerminal, the break signal is usually issued by pressing the Function key and 
the Break key, sometimes located on the Page Down or Pause key. Table 1-8, earlier 
in the chapter, documents where you can find standard break key combinations for all 
terminal-emulation software, platforms, and operating systems. 

e On HyperTerminal, the break signal is issued by pressing the Ctrl-Break/Pause key 
sequence. 

e On Windows NT, you must configure NT to send the break signal with a function key. 
Set the Break by entering the characters *$B (Shift 6, Shift 4, and uppercase B). 
HyperTerm 5.0 private edition sends the Break for the Windows NT platform without 
any additional configuration. 

e When using any other terminal-emulation software, consult the manufacturer's 
instructions on sending a break signal. 


When you see the abort message, you are ready to proceed. If you don't recall what type of 
routers support CONFREG, this is a good point to key in the ? for help and look for the 
CONFREG utility. In Example 1-39, you can see what the output from the ? looks like on the 


access server. 


Example 1-39 Output from the ? Command on Router That Doesn't 
Support CONFREG 


>? 
Toggle cache state 
[filename] [TFTP Server IP address | TFTP Server Name] 
Load and execute system image from ROM or from TFTP server 


Wm 


Stack trace 
[filename] [TFTP Server IP address | TFTP Server Name] 
Load system image from ROM or from TFTP server, but do not 
begin execution 
O Show configuration register option settings 
P Set the break point 
Ss 
Als 


C [address] Continue execution [optional address] 

D/SMLV Deposit value V of size S into location L with modifier M 
E/SML Examine location L with size S with modifier M 

G [address] Begin execution 

H Help for commands 

- Initialize 

K 

L 


Single step next instruction 
function Test device (? for help) 


Deposit and Examine sizes may be B (byte), L (long) or S (short). 
Modifiers may be R (register) or S (byte swap). 
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Register names are: DO-D7, AO-A6, SS, US, SR, and PC 
> 


Example 1-40 illustrates the same break, followed by the ? command; however, this time, it 
was performed on a router that supports CONFREG. 


Example 1-40 A Successful Break, Followed by the Output from the ? 
Command on Router That Supports CONFREG 


System Bootstrap, Version 5.3(16) [richardd 16], RELEASE SOFTWARE (fcl) 
Copyright (c) 1996 by cisco Systems, Inc. 
C4500 processor with 16384 Kbytes of main memory 


monitor: command "boot" aborted due to user interrupt 
rommon 1 > 
rommon 1 > ? 


alias set and display aliases command 

boot boot up an external process 

break set/show/clear the breakpoint 

confreg configuration register utility 

cont continue executing a downloaded image 
context display the context of a loaded image 
cookie display contents of cookie PROM in hex 
dev list the device tabl 

dir list files in file system 

dis disassemble instruction stream 

dnid serial download a program module 
frame print out a selected stack frame 

help monitor built in command help 

history monitor command history 

meminfo main memory information 

repeat repeat a monitor command 

reset system reset 

set display the monitor variables 

stack produce a stack trace 

sync write monitor environment to NVRAM 
sysret print out info from last system return 
unalias unset an alias 

unset unset a monitor variable 


rommon 2 > 


Set bit 6 of the register to 1 to ignore NVRAM on startup. This is done by keying in O/ R hex- 
value and then pressing Enter. Then initialize, or reload, the router by keying in init. 
Example 1-41 demonstrates this procedure. 


Example 1-41 Setting Bit 6 to |gnore NVRAM, Followed by the 
initialization Command 


System Bootstrap, Version 5.2(8a), RELEASE SOFTWARE 
Copyright (c) 1986-1995 by cisco Systems 
2500 processor with 14336 Kbytes of main memory 


Abort at 0x10205A6 (PC) 
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>o/r 0x2142 
>init 


System Bootstrap, Version 5.2(8a), RELEASE SOFTWARE 
Copyright (c) 1986-1995 by cisco Systems 


On a router that supports CONFREG, this process is just as straightforward. Example 1-42 


demonstrates how this procedure is done on such a platform. In this example, a Cisco 4700 
series router is used. 


Example 1-42 Setting Bit 6 to |gnore NVRAM, Followed by the reset 
Command 


rommon 1 > confreg 


Configuration Summary 
enabled are: 
load rom after netboot fails 
console baud: 9600 
boot: image specified by the boot system commands 
or default to: cisco2-C4500 


do you wish to change the configuration? y/n [n]: y 
enable "diagnostic mode"? y/n [n]: n 

enable "use net in IP bcast address"? y/n [n] n 
disable "load rom after netboot fails"? y/n [n]: n 
enable "use all zero broadcast"? y/n [n]: n 

enable "break/abort has effect"? y/n [In]: n 

enable "ignore system config info"? y/n [n]: y 
change console baud rate? y/n [n]: n 

change the boot characteristics? y/n [mae at 


Configuration Summary 
enabled are: 
load rom after netboot fails 
ignore system config info 
console baud: 9600 
boot: image specified by the boot system commands 
or default to: cisco2-C4500 


do you wish to change the configuration? y/n [n]: n 
You must reset or power cycle for new config to take effect 
rommon 2 > reset 


System Bootstrap, Version 5.3(16) [richardd 16], RELEASE SOFTWARE (fcl) 
Copyright (c) 1996 by cisco Systems, Inc. 


When the router reloads, it will no longer have a running-configuration. The router will still 
have a startup-configuration, which is stored in NVRAM. To view this configuration, first enter 
enable mode and then enter the show startup-configuration command. 
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If you want to preserve the existing configuration, perform the following steps, paying strict 
attention to the order. 


Step 1. Enter enable mode with enable. 


Step 2. Copy the startup-config to running-config with copy startup-config 
running-config. 


Step 3. Enter the configuration mode, and change the boot register back to the 
normal configuration with configure-register 0x2102. 


Step 4. Bring up all interfaces because they will be in the default down status. 
Step 5. Configure a new enable password. 


Step 6. Save the configuration with copy running-config startup-config. 
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Lab 2: Password Recovery on a Catalyst 5500—Part | 
Practical Scenario 


As with routers, sometimes you might need to perform a password-recovery procedure on 
switches. 


Lab Exercise 


Along with the routers used for the lab, you have received a used Catalyst 5500 switch. The 
switch is password-protected. To use the switch in this lab, you must perform password 
recovery on the switch and secure access with a new password. 


Lab Objectives 


e Perform password recovery on Catalyst 5500. 
e Set anew enable password on the Catalyst 5500. 


Equipment Needed 


e One Cisco Catalyst switch—the switch can be either a 5000, a 5500, or a 4000 series 
switch. 


Physical Layout and Prestaging 


The switch used must have some previous configuration and an enable password set. 
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Lab 2: Password Recovery on a Catalyst 5500—Part Il 


Lab Walkthrough 


For the first 30 seconds during switch initialization, the password and enable password are 
both the Enter key. As soon as the Cisco Systems Console message appears, you can 
begin configuration. 


First, enter enable mode. The switch will prompt you for a password; simply press the Enter 
key. Second, configure a new password with the set password command. Again, the switch 
will prompt you for an old password, press Enter again. Finally, before 30 seconds are up, 
configure a new enable password. This is done with the command set enablepass. For the 
last time, the switch will prompt you for an old password; press Enter one more time. The 30 
seconds needed to set the passwords can go by quickly. If you're having trouble getting the 
passwords set, try setting the new password to just the Enter key. This allows you to type 
Enter twice when prompted for the old and new passwords. Example 1-43 illustrates this 


process of key-ins. 


Example 1-43 Password Recovery on a Catalyst 5500 


Console> en 


Enter password: ‘ -Enter key pressed 

Console> (enable) set pass 

Enter old password: ‘ -Enter key pressed 

Enter new password: ‘ -Enter key or new password 

Retype new password: y -Enter or new password 

Password changed. 

Console> (enable) set enablepass 

Enter old password: y -Enter key pressed 

Enter new password: ‘ -Enter key or new password 
— 


Retype new password: -Enter or new password 
Password changed. 


Console> (enable) 
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Lab 3: Upgrading the IOS and Restoring a Configuration from TFTP 
Server—Part | 


Practical Scenario 


Sometimes, in the field, you must perform an Cisco |OS Software upgrade, but you do not have 
local access to the router. You can still perform the upgrade by making an adjacent Cisco router a 
TFTP server. 


Lab Exercise 


In this practical exercise, you upgrade one router's |OS from another router's Flash memory. A 
second part of this exercise consists of copying configs to and from a TFTP server. 


Lab Objectives 


e Refer to Figure 1-16, and configure the network as shown—do not configure the loopback 
address at this time. 


Figure 1-16. Lab 3: Physical Layout and IP Address Map 


Physical Layout & 
IP address map 


rosewell ufo 
ro Fo 
EQ: IP-172.16.16. 1/24 EQ:IP-172.16.16.2/24 


TFIP Server 
IP-172.16.16.254/24 


e To prevent future "crashes" of the Cisco |OS Software on the router rosewell, copy the 
new Cisco |OS Software from the router ufo to the router rosewell. 

e Using TFTP, TFTP the startup-config from router ufo to the TFTP server 172.16.16.254. 
Edit the configuration with Wordpad, and change the host name to w-balloon. TFTP the 
configuration back to the router's startup-config. Reload the router. 


Equipment Needed 113 


e Two Cisco routers and one Ethernet hub 
e One workstation with terminal-emulation software, TFTP software, and TCP/IP configured 
per Figure 1-16 


Physical Layout and Prestaging 


TCP/IP must also be configured on this workstation per Figure 1-16. 


114 


Lab 3: Upgrading the IOS and Restoring a Configuration from a 
TFTP Server—Part Il 


Lab Walkthrough 


The first step in this lab is to configure all the equipment as shown in Figure 1-16. Also attach 


a workstation to the same physical segment. When all the devices can ping each other, you 
can move on. 


This lab introduces another new concept—making the router function as a TFTP server. To 
make a router perform as a TFTP server, add the command tftp-server [flash | rom] 
filename from configuration mode. In Example 1-44, first you perform a show flash 
command to view the files available on Flash memory (be sure to note the filename). From 
the configuration mode, enter the command tftp-server flash filename. To avoid typing 
mistakes, which is a common problem on Flash upgrades, use cut-and-paste techniques for 
the filename. 


Example 1-44 Making a Router Serve as a TFTP Server 


ufo# 
ufo#show flash 


System flash directory: 
File Length Name/status 
1 8102652 ¢2500-—js-1_112-16.bin 
[8102716 bytes used, 285892 available, 8388608 total] 
8192K bytes of processor board System flash (Read ONLY) 


ufo#conft t 

Enter configuration commands, one per line. End with CNTL/Z. 
ufo (config) #tftp-server flash c2500-—js—-1_112-16.bin 

ufo (config) #*Z 

ufo# 


Moving over to rosewell, you can now upgrade the |OS through TFTP on router ufo. To 
perform this task, use the copy tftp flash command, and answer the questions accordingly. 
Use ufo as the TFTP server, and use c2500-js-|_112-16.bin as the filename. Example 1-45 


demonstrates the upgrade of rosewell from ufo. 


Example 1-45 Upgrading the |OS by Using TFTP 


rosewell# 
*~ copying from the server to the router 
KkKK*K NOTICE KKKK 
Flash load helper v1.0 
This process will accept the copy options and then terminate 
the current system image to use the ROM based image for the copy. 
Routing functionality will not be available during that time. 
If you are logged in via telnet, this connection will terminate. 


Users with console access can see the results of the copy operation. 
meee RRR RAK sae 
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Proceed? [confirmly 


System flash directory: 
File Length Name/status 
i 8034308 c2500-js-1_112-11.bin 
[8034372 bytes used, 8742844 available, 16777216 total] 
Address or name of remote host [255.255.255.255]? 172.16.16.2 
Source file name? c2500-js-1_112-16.bin 
Destination file name [c2500-js-1_112-16.bin]? c2500—js—-1_112-16.bin 
Accessing file *¢2500=js-1.112-16.bin" on 172.16.16.2%4. 
Loading c2500-js-1_112-16.bin .from 172.16.16.2 (via Ethernet0O): ! [OK] 


Erase flash device before writing? [confirmly 
Flash contains files. Are you sure you want to erase? [confirmly 


Copy 'c2500-js-1_112-16.bin' from server 
as 'c2500-js-1_112-16.bin' into Flash WITH erase? [yes/no]yes 


00:01:15: %SYS-5-RELOAD: Reload requested "che router reloads 
SERVICE_MODULE(1): self test finished: Passed 

SSYS-4-CONFIG_NEWER: Configurations from version 11.2 may not be correctly under 
stood. 

SP LHe. -e2500=jS=1._ 112=16.bin trom. 172.16.16.2 to: flash 


System flash directory: 
File Length Name/status 
i 8034308 ¢2500—js=1_112-11.bin 
[8034372 bytes used, 8742844 available, 16777216 total] 
Accessing file: "62500=—js=1_112=-16.bin" on 172.176.116.254. 


Loading c2500-js-1_112-16.bin .from 172.16.16.2 (via Ethernet0O): ! [OK] 
Erasing device... eeeeeceeeceecececeeeceeceeeeecececececeeceeeceeeececeeceeceeeeceeeeeeceeee 
— 


Loading c2500-js-1_112-16.bin from 172.16.16.2 (via EthernetO): [H!!!lrurrrrryere 
<<<text omitted>>> 
aon ania ia oi aie hae hae ee Rh a 


[OK — 8102652/16777216 bytes] 


Verifying checksum... OK (0x8DCB) 
Flash copy took 0:04:40 [hh:mm:ss] 
SFLH: Re-booting system after download 
F3: 8004052+98568+315656 at 0x3000060 
<<<text omitted>>> 


00:00:23: %SYS-5-RESTART: System restarted -—- 

Cisco Internetwork Operating System Software 

IOS (tm) 2500 Software (C2500-JS-L), Version 11.2(16), RELEASE SOFTWARE (fcl) 
Copyright (c) 1986-1998 by cisco Systems, Inc. 

Compiled Tue 06-Oct-98 11:54 by ashah 

rosewell>show flash 


System flash directory: 
File Length Name/status 
— 
[8102716 bytes used, 8674500 available, 16777216 total] 
16384K bytes of processor board System flash (Read ONLY) 
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rosewell> 


After the Flash download, the router verifies the checksum of the file before reloading. At the 
end of the example, you perform a show flash command to verify that the new IOS is place. 


The second part of the lab requires you to copy the startup-configuration from the router ufo, 
modify it by changing the hostname to w-balloon, and then copy it back to its original 
location. To accomplish this, you use the copy startup-config tftp command and follow the 
prompts. Before you do this, it is always a good idea to ensure that the router can ping the 
TFTP server. Example 1-46 demonstrates the use of the ping and copy commands. 


Example 1-46 Copying the startup-config to a TFTP Server 


ufot#ping 172.16.16.254 


Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.16.254, timeout is 2 seconds: 


Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms 
ufo#copy startup-config tftp 
Remote host []? 172.16.16.254 


—— 


Name of configuration file to write [ufo-confg]? -—--- carriage return 
Write file ufo-confg on host 172.16.16.254? [confirm]ly 
Writing ufo-confg !! [OK] 


ufo# 


It is important to note that, as its name implies, TFTP is trivial. That means that TFTP has no 
way of overwriting files or prompting the user for input after the copy process begins. If you 
tried this same procedure again, you would get an error because the file already exists from 
your first copy. You might or might not experience this error; some versions of TFTP have 
options that automatically overwrite the existing file if it exists. Example 1-47 demonstrates 
the error when a duplicate file is found and cannot be overwritten. 


Example 1-47 TFTP Copy Error, Duplicate File Found 


ufo#copy startup-config tftp 
Remote host []? 172.16.16.254 


—— 


Name of configuration file to write [ufo-confg]? ---- return 
Write file ufo-confg on host 172.16.16.254? [confirm]ly 
Writing ufo-confg 
TFTP: error code 0 received —- File exists 
[Failed] 


ufo# 


When the file is successfully copied to your PC, use Microsoft Wordpad to edit it. Locate the 
HOSTNAME field and change ufo to w-balloon. Finally, copy the file back to the router by 
using the copy tftp startup-config command. When the file is copied back to the router, 
you might want to view it; this can be done using the show startup-config command. To 
activate the new configuration, either reload the router or perform the copy startup-config 
running-config command. When this is done, the host name should be changed from ufo to 
w- balloon. Example 1-48 demonstrates this process. 
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Example 1-48 Copy Configurations from a TFTP Server 


ufo#copy tftp startup-config 

Address of remote host [255.255.255.255]? 172.16.16.254 

Name of configuration file [ufo-confg]? 

Configure using ufo-confg from 172.16.16.254? [confirm]ly 

Loading ufo-confg from 172.16.16.254 (via Ethernet0O): ! 

[OK - 564/32723 bytes] 

[OK] 

ufo# 

SSYS-5-CONFIG_NV: Non-volatile store configured from ufo-confg by console tftp f 
rom 172.116.106.254 


ufo#show startup-config 

Using 564 out of 32762 bytes 

! 

version 11.2 

no service password-encryption 
no service udp-small-servers 
no service tcp-small-servers 

! 

hostname W-BALLOON 


interface Ethernet0O 
ip address 172;16<16.2° 255.255.2550 
no ip route-cache 
no ip mroute-cache 


interface Serial0 
no ip address 

no ip route-cache 
no ip mroute-cache 
| 

interface Seriall 
no ip address 

ufo# 
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Lab 4: Configuring an Access Server—Part | 
Practical Scenario 


An access server provides out-of-band management to an entire stack of routers. This can 
provide an easy method of configuring access to a variety of Cisco routers and switches from 
a single device. 


Lab Exercise 


In this practical exercise, you configure an access server for reverse Telnet access to all the 
routers and switches in your rack. This enables you to configure multiple routers and 
switches without having to manually switch the console cable between them. 


Lab Objectives 


e Add a loopback interface to the access router. This address should be 201.201.1.1. 
e Configure an IP host table so that the following exists: 


- Hostname rl performs a reverse Telnet to the first router in your stack. 


- Hostname r2 performs a reverse Telnet to the second router in your stack, 
and so on. 

e Minimize contention for the asynchronous lines. 

e Prevent router sessions from timing out on all remote routers. 


Equipment Needed 


e Two Cisco routers and one Cisco 2509-2511, or a 2600 series router with an 
asynchronous module for the access server. The access server also requires the octal 
cable. 


Physical Layout and Prestaging 


e One workstation connected by its COM port to a Cisco 2509-2511, through Cisco 
black or light-blue rolled cable is required. 

e Connect the octal cable labeled 1 to an R1 or the first router's console port. Repeat 
this process for every router or switch in lab. 
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Lab 4: Configuring an Access Server—Part II 
Lab Walkthrough 


After connecting all the console ports to the octal cable of your access server, you can begin 
to configure the access server to support reverse Telnet sessions. To configure a reverse 
Telnet session, you need to know what the absolute or line entry numbers are for the TTY 
lines that you are working on. To display the line entries, perform the show line command. 
In Example 1-49, the line entries are from 1 to 16 for the TTY session. You have two to five 
routers in this lab, so you use the values 2001 to 2005 for a Telnet port on reverse Telnet 
sessions. 


Example 1-49 Display of the show line command 


Router#show line 


Tty Typ Tx/7 Rx A Modem Roty AccO AccI Uses Noise Overruns Leigh st 

* 0. CRY = - = - = 0 al 0/0 = 

i ea big 9600/9600 - = = = = 0 0 0/0 = 

2 Ory 9600/9600 - = = = - ) 1 0/0 = 

oT Ty 9600/9600 - = = = = 0 0) 0/0 = 

4 TTY 9600/9600 - = = = = ) ) 0/0 = 

5 TTY 9600/9600 - = = = = 0 ) 0/0 = 

6 “TTY 9600/9600 - = = = - 0 a 0/0 = 

x TTY 9600/9600 - = = = - 0 a 0/0 = 

o TTY 9600/9600 - = = = = 0 0 0/0 = 

9 TTY 9600/9600 - = = = = 0 0 0/0 = 

10 ‘TTY 9600/9600 - = = = = ) 0 0/0 = 

i ey 9600/9600 - = = = = ) ) 0/0 = 

12 TTY 9600/9600 - = = = = 0 0 0/0 = 

13 DEY 9600/9600 - = = = = 0 0 0/0 = 

14 TTY 9600/9600 - = = = = 0 0 0/0 = 

15 DT. 9600/9600 - = = = = ) 0 0/0 = 

16. TTY 9600/9600 - = = = = ) 0) 0/0 = 

17 AUX 9600/9600 - = = = = 0 0) 0/0 = 

18 VTIY 7 = = = = 0 0 0/0 7 

19 VIY = = = = = 0 0 0/0 = 

20 vVTY = = = = - 0 0 0/0 7 

21, VIY = = = = = 0 0 0/0 i 

Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Time 

22 VTY 7 = = 7 - 0 0 0/0 - 
Router# 


Now that you know the absolute line values, you can configure the access server to support 
reverse Telnet. From the configuration mode, enter a host name of access-server, followed 
by the lines that you need for the reverse Telnet sessions. Enter ip host rl 200x 
201.201.1.1, where x ranges from 1 to 5. You also need to add a Loopback 0 interface with 
an IP address of 201.201.1.1/24. Example 1-50 illustrates this process. 


Example 1-50 Configuration of |!P Host Names for Reverse Telnet 
Sessions 
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Router# 

Router#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
Router (config) #hostname access-server 
access-—server (config) #ip host rl 2001 201.201. 
access-—server (config) #ip host r2 2002 201.201. 
access-—server (config) #ip host r3 2002 201.201. 
access-—server (config) #ip host r3 2003 201.201. 
access-—server (config) #ip host r4 2004 201.201. 
access-—server (config) #ip host r5 2005 201.201. 
access-—server (config) #interface loopback 0 
access-—server(config-if)#ip address 201.201.1.1 255.255.255.0 
access-server (config-if) #exit 

access-server (config) # 


PRPRPRPRPR 
PRRPPRPRPR 


The final part of configuring an access server involves configuring the line entries to support 
reverse Telnet. This can be accomplished by adding transport input all on the appropriate 
lines. In this particular lab, we will go one step further and reduce contention for the line by 
adding the no exec command. This is only for convenience, and it is not a requirement of 
configuring a reverse Telnet session. Example 1-51 completes the access server's 
configuration for reverse Telnet. 


Example 1-51 Configuring the Absolute Lines for Support of Reverse 
Telnet, and Disabling the Exec 


access-—server (config) #line 1 5 

access-—server (config-line) #transport input all 
access-—server (config-line) #no exec 
access-—server (config-line) #*Z 

access-server# 


To test the configuration, simply key in rl, and a session opens to R1. If this session is 
rejected, be sure to perform a clear line x, where x is the absolute line number of the 
session that was rejected. Example 1-52 lists the entire configuration of the access server. 


Example 1-52 Complete Listing of a Router Configured as an Access 
Server 


access-server#wr t 
Building configuration... 


Current configuration: 

! 

version 12.0 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
! 


hostname access-server 
1 


ip subnet-zero 
ip host: 11. 2001. 201.201.1471 
ip. host, r2 2002:..201..201<1.1 
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ip host r3 2003 201.201.1210 
ip host r4 2004 201.201.1.1 
ip host. 25 ZOOS. 200201 21.4 
! 

interface LoopbackO 

ip address. 201..201.1.1 255.255.255:.0 
no ip directed-broadcast 

! 

interface Ethernet0O 

no ip address 

no ip directed-broadcast 
shutdown 

! 

interface Serial0 

no ip address 

no ip directed-broadcast 
no ip mroute-cache 
shutdown 

! 

interface Seriall 

no ip address 

no ip directed-broadcast 
shutdown 

! 


ip classless 

! 

line con 0 

transport input none 
line 15 

no exec 

transport input all 
line 6 16 

line aux 0 

line vty 0 4 

! 


end 


access-server# 


The final part of the lab instructed you to configure the Telnet session so that it would not 
time out after a period of inactivity. To accomplish this, add the command no exec-timeout 
on Line O, the console port of the routers connected to the access server. Adding this 
command forces the routers not to time out the console port and log you off because of 
inactivity. 
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Lab 5: Configuring a Frame Relay Switch—Part I 


Practical Scenario 


A Frame Relay switch can be of great service both in the field and in practice. A Frame Relay 
switch can be deployed in a lab to help model Frame Relay services that are similar to a 
production environment. 


Lab Exercise 


In this practical exercise, you configure a multipoint fully meshed Frame Relay network. This lab 
focuses only on the switching aspects of Frame Relay, not on the end or DTE devices. 


Lab Objectives 


e Configure a Cisco router to perform a Frame Relay switching function, as depicted in 
Figure 1-17. 


Figure 1-17. Lab 5: Physical Layout for Frame Relay Switching 


frame_switch 


51-DCE 50-DCE 
DLCI-112 DLCI-21 
L DLCI-113 DLCI-23 3 
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PVC Layout DLCI-32 
DLCI 112 maps to DLC! 21 V.35 LMl-ansi 
DLC! 113 maps to DLC! 31 
DLCI| 32 maps to DLC! 23 | S0-DTE 
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e Configure all PVCs with ANSI LMI as the diagram depicts. The PVC mapping is as follows: 
- DLC! 112 maps to DLC! 21. 
- DLC! 113 maps to DLC! 31. 
- DLC! 32 maps to DLCI 23. 


Equipment Needed 
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e Three Cisco routers with serial ports and one other Cisco router to perform the role of the 
Frame Relay switch. The Frame Relay switch must have three usable serial ports. 
e A total of six serial cables, or three sets of DTE-to-DCE serial cables. 


Physical Layout and Prestaging 


Figure 1-17 shows the physical layout for this lab. 
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Lab 5: Configuring a Frame Relay Switch—Part Il 


Lab Walkthrough 


The Frame Relay switch in this lab functions as a fully meshed Frame Relay service. A fully meshed 
Frame Relay service has a PVC not only to a central site, but also to every other site. This can lead 
to several scaling problems when a large number of sites are involved. Some Layer 3 routing 
issues, such as split horizons, also can occur on a multipoint network. Chapter 5 discusses this in 


more depth. 


To configure Frame Relay switching, you need to perform the following tasks: 


Step 1. Enable Frame Relay switching. 


Step 2. Configure interface LMI and Frame Relay interface type. 


Step 3. Configure PVCs with the frame-relay route command. 


First, enable Frame Relay switching using the frame-relay switching global command from 
configuration mode. Second, configure the serial interfaces for Frame Relay switching, as shown in 
Figure 1-17. To perform this, use the encapsulation frame-relay command, along with the 
commands frame-relay intf-type dce command and frame-relay Imi-type ansi on serial 
Interface 5. Example 1-53 highlights the Frame Relay switch configuration. 


Example 1-53 Frame Relay Multipoint Configuration 


hostname frame_switch 


! 
! 


interface Ethernet0 


interface Seriall 
no ip address 
encapsulation frame-relay 
clockrate 56000 
frame-relay intf-type dce 


<<<text omitted>>> 

! 

interface Serial5 

no ip address 
encapsulation frame-relay 
clockrate 56000 


frame-relay intf-type dce 


eae ue ecennoeEe = =—=—«_ «Ee eee 
Eiees te eyerorren ae eee ll Ee eee ee 
! 

<<<text omitted>>> 

end 


To see if your Frame Relay switch is working, you need to configure the DTE, or router side of the 
network. When this is complete, the PVCs will become "active." Example 1-54 illustrates the Frame 
Relay configuration of R1, R2, and R3. 


Example 1-54 The Significant Configuration Portions of R1, R2, and R3 


hostname rl 
J 
interface Serial0O 
ip address 172.16.17.1 255.255.255.0 
encapsulation frame-relay 
frame-relay map ip 172.16.17.2 112 broadcast 


frame-relay map ip 172.16.17.3 113 broadcast 
! 


hostname r2 

! 

interface Serial0O 

ip address 172.16.17.2 255.255.255.0 

no ip directed-broadcast 

encapsulation frame-relay 

no ip mroute-cache 

frame-relay map ip 172.16.17.1 21 broadcast 
frame-relay map ip 172.16.17.3 23 broadcast 


hostname r3 

! 

interface Serial0O 

ip address 172.16.17.3 255.255.255.0 

no ip directed-broadcast 

encapsulation frame-relay 

no ip mroute-cache 

frame-relay map ip 172.16.17.1 31 broadcast 
frame-relay map ip 172.16.17.2 32 broadcast 
frame-relay lmi-type ansi 
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When this is complete, enter the show frame-relay route command to ensure that all 
connections are up and active. Also verify that LMI is correctly configured with the show frame- 
relay Imi command. These two commands manifest themselves in Example 1-55. 


Example 1-55 The show frame-relay route and show frame-relay Imi 
Commands 


frame_switch#show frame-relay route 


Input Intf Input Dlci Output Intf Output Dlci Status 
Serial0d 24 Seriall 12 active 
Serialo 23 Serial5 32 active 
Seriall 112 Serial0d Zi. active 
Seriall 3 Serial5 31 active 
Serial5 cul Seriall TLS active 
Serial5 32 Serial0d 23 active 


frame_switch# 
frame_switch#show frame-relay lmi 


LMI Statistics for interface Serial0O (Frame Relay DCE) LMI TYPE = CISCO 


Invalid Unnumbered info 0 Invalid Prot Disc 0 
Invalid dummy Call Ref 0 Invalid Msg Type 0 
Invalid Status Message 0 Invalid Lock Shift 0 
Invalid Information ID 0 Invalid Report IE Len 0 
Invalid Report Request 0 Invalid Keep IE Len 0 
Num Status Enq. Revd 188 Num Status msgs Sent 188 
Num Update Status Sent 0 Num St Eng. Timeouts 0 


LMI Statistics for interface Seriall (Frame Relay DCE) LMI TYPE = CISCO 


Invalid Unnumbered info 0 Invalid Prot Disc 0 
Invalid dummy Call Ref 0 Invalid Msg Type 0 
Invalid Status Message 0 Invalid Lock Shift 0 
Invalid Information ID 0 Invalid Report IE Len 0 
Invalid Report Request 0 Invalid Keep IE Len 0 
Num Status Enq. Revd 188 Num Status msgs Sent 188 
Num Update Status Sent 0 Num St Eng. Timeouts 0 


LMI Statistics for interface Serial5 (Frame Relay DCE) LMI TYPE = ANSI 


Invalid Unnumbered info 0 Invalid Prot Disc 0 
Invalid dummy Call Ref 0 Invalid Msg Type 0 
Invalid Status Message 0 Invalid Lock Shift 0 
Invalid Information ID 0 Invalid Report IE Len 0 
Invalid Report Request 0 Invalid Keep IE Len 0 
Num Status Enq. Revd 185 Num Status msgs Sent 185 
Num Update Status Sent 0 Num St Eng. Timeouts 1 


frame_switch# 
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Lab 6: Configuring Remote Access to the Lab—Part | 


Practical Scenario 


Attaching a modem to an auxiliary port or an asynchronous line provides a useful out-of-band 
method of management for routers and switches. You can provide a complete "configuration 
safety net" for your network with the placement of an access server at a central site. The access 
server would connect the console ports of all the routers at the central site; when combined with 
an analog modem, this provides a reliable method of access to your network. 


Lab Exercise 


This is the final lab of Chapter 1, and it serves as the springboard for all the other labs in this 
text. From this point on, you use this access server to configure the routers in the lab. To further 
enhance access to the lab, you add a modem to the last asynchronous port on the access server. 
This device serves as a key device in modeling some of the most complex internetworks known 
today. Therefore, the name Skynet is used to give the access server and models some character. 


Lab Objectives 
e Refer to Figure 1-18, and cable the access server as shown. 


Figure 1-18. Lab 6: Physical Layout 
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e Configure a reverse Telnet session from the access server to all the routers attached to 
Octal cable. Use an IP host-name table to ease the use of reverse Telnet sessions. 

e Configure the modem on the asynchronous line to accept an analog dialup session into the 
router. 


Equipment Needed 


e One Cisco 2509-2511, Cisco 2600, or Cisco 3600 for the access server, along with the 
asynchronous module and octal cable. 

e One to five other routers. (Only one is needed to complete this lab.) 

e One analog modem, modem head-shell, and Cisco rolled cable. 
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Physical Layout and Prestaging 


Asynchronous connections should be connected as noted in Figure 1-18. 


129 


Lab 6: Configuring Remote Access to the Lab—Part Il 


Lab Walkthrough 


The first step in configuring Skynet is to attach the routers and the modem as indicated in Figure 
1-18. After attaching all the physical devices, verify what absolute line they exist on through the 
show line command, as demonstrated in Example 1-56. Note the column on the left side—the 
asynchronous lines are the ones denoted as TTY. 


Example 1-56 The show line Command Performed on the Access Server 


Router#show line 


Tuy Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int 
erry: = a ie = = 0 0 0/0 = 
1. TTY 9600/9600 - = - = = 0 0 0/0 - 
*& 2. RY 9600/9600 - = - = = 0 al 39 £110 - 
canes timed iD 9600/9600 - = - - = 0 a 3/11 7 
4 TTY 9600/9600 - = = = = 0 il 0/0 = 
9. TY, 9600/9600 - = = = = 0 1 0/0 = 
G. UT 9600/9600 - = = = = 0 il 0/0 = 
YL, 9600/9600 - = = = = 0 0 0/0 = 
So TTY 9600/9600 - - = a = 0 0 0/0 = 
9 TITY 9600/9600 —- = = - = 0 0 0/0 = 
10 “ITY 9600/9600 - - = = = 0 0 0/0 = 
LT PTY 9600/9600 - = = = = 0 0 0/0 = 
12: SETY 9600/9600 - = = = = 0 0 0/0 = 
13 ETY 9600/9600 - = = = = 0 0) 0/0 = 
14 TTY 9600/9600 - = - = - 0 0 0/0 - 
15 TTY 9600/9600 - = - = = 0 0 0/0 - 
16 TTY 9600/9600 - = - = - 0 0 0/0 - 
17 AUX 9600/9600 - = = = = 0 0 0/0 = 
18 VTY = 7 - 7 = 0 0 0/0 7 
19 VTY = = 7 = = 0 0 0/0 7 
20 VTY - - - - - 0 0 0/0 = 
2A VT = = = a = 0 0/0 = 
Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int 
22 VTY = = = = = 0 0 0/0 = 
Router# 


Lines 1 through 4 are the TTY lines to which you have attached the routers. Therefore, you need 
to add the following to these lines: 


e transport input all 
e noexec 


To make reverse Telnet sessions easier to open, you add a host table for each router, pointing to 
ports 2001 through 2004. To facilitate the reverse Telnet session, you also need to add a 
loopback interface. Example 1-57 shows the configuration of skynet_access. 


Example 1-57 Initial Configuration of the Access Server Called 
skynet_access 
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Enter configuration commands, one per line. End with CNTL/Z. 
Router (config) #hostname skynet_access 


To complete the lab, you must configure Line 5 for a modem. To accomplish this task, add the 
following to Line 5: 


e transport input all 
e modem inout 
e modem autoconfigure discovery 


In Example 1-58, you add the preceding commands to Line 5. Be sure to also include an enable 


password—without this, the remote session will not be capable of entering privilege mode to 
configure the router. 


After adding the new commands, perform the show line command, followed by the show line 5 
command. In the resulting output, look for Line 5 to be configured as a modem. Also ensure that 
the modem is correctly configured and that CTS is detected. 


Example 1-58 The Line Configuration for a Modem and show line 
Command in Use 
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ity Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int 

S30 “CTX = - 7 7 7 0 0 0/0 = 

A. TY 9600/9600 —- = = = = 0) 0 0/0 = 

2. TTY 9600/9600 —- = = = 7 0 1 145/437 7 

3 TTY 9600/9600 - = = = = ©) al 109/328 = 

A. PTY 9600/9600 - = = = = ©) i 0/0 = 

5 “TTY 175200/115200= 1no0ut = = = ©) 1, 0/0 = 

6 TTY 9600/9600 —- - - 7 - ©) al 0/0 - 

7 TTY 9600/9600 —- - - = = 0 0 0/0 - 

8 TTY 9600/9600 - 7 7 7 7 0 0 0/0 - 

o: TTY 9600/9600 - = = = = 0 0 0/0 = 

LO: 2TY 9600/9600 - = = = = 0) 0) 0/0 = 

fo. EY 9600/9600 - = = = = 0 0 0/0 = 

12 TITY 9600/9600 - = = = = 0 0 0/0 = 

LLY 9600/9600 —- = = 7 = 0 0 0/0 = 

14 TTY 9600/9600 - = = a = 0 0) 0/0 = 

15 “‘LTY 9600/9600 —- = = 7 = 0 0 0/0 = 

16 TTY 9600/9600 - = = = = 0 0 0/0 = 

17 AUX 9600/9600 - = = = = 0) 0 0/0 = 

18 VTY 7 = = - = 0 0 0/0 = 

19 VT¥ = - - = - ©) 0 0/0 - 

20 vTIY - = = 5 = 0 0 0/0 - 

21 VTY = - - - - 0 0 0/0 = 

Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int 

22. VUY = = = = = 0 0 0/0 = 
skynet_access#show line 5 

ity Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns int 

5 TTY 115200/115200— inout = = = ©) iL 0/0 = 


Line 5, Location: "", Type: "" 

Length: 24 lines, Width: 80 columns 

Baud rate (TX/RX) is 115200/115200, no parity, 2 stopbits, 8 databits 
Status: No Exit Banner, Modem Detected 

Capabilities: Modem Callout, Modem RI is CD, Modem Discovery 

Modem state: Idle 

Group codes: 0 

Modem hardware state: CTS noDSR DTR RTS, Modem Configured 

Special Chars: Escape Hold Stop Start Disconnect Activation 


AA 


x none 7 = none 
Timeouts: Idle EXEC Idle Session Modem Answer Session Dispatch 
00210300 never none not set 
Idle Session Disconnect Warning 
never 
Login-sequence User Response 
00:00:30 
Autoselect Initial Wait 
not set 


Modem type is usr_sportster. 

Session limit is not set. 

Time since activation: never 

Editing is enabled. 

History is enabled, history size is 10. 
DNS resolution in show commands is enabled 
Full user help is disabled 

Allowed transports are lat pad v120 mop telnet rlogin nasi. Preferred is lat. 
No output characters are padded 

No special data dispatching characters 
skynet_access# 
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When the configuration is complete, you can test it by making an analog connection by using 
HyperTerminal or another terminal emulator, such as Procomm. 


From this point on, the configuration of the access server will remain fairly static. You should have 
access to all the routers in the stack through reverse Telnet, along with analog access to the lab. 


You now should have the groundwork necessary to begin practical studies in internetworking. 
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Part Il: Modeling LANs 


Chapter 2 LAN Protocols: Configuring Catalyst Ethernet and Token Ring Switches 
Part || Modeling LANs 
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Chapter 2. LAN Protocols: Configuring Catalyst 
Ethernet and Token Ring Switches 


In the realm of networking, no technology is outpacing that of local-area networks (LANs). In 
less than a decade, LANs have become common in many homes and are a "must" for any 
small business. Many, if not all, new commercial buildings are wired with some type of copper 
or fiber cable plant for local-area networking. Even when you travel, many hotels offer the 
use of a LAN to access the Internet. Many new residential communities are incorporating 
what you might call community-area networks, or CANs, in which homes will be connected 
through LANs to provide Internet service or another related service. 


Not only is the number of LANs multiplying, but bandwidth also is multiplying exponentially. 
The standards that have been written and adopted for LAN protocols in the last 10 years 
have been tremendous. For example, in March 2002, 10-Gb Ethernet, 802.3ae, is scheduled 
for formal ratification, and 100-Gb Ethernet seems inevitable. To put leaps in technology like 
this in perspective, we use the less than scientific "Twinkie Theory." If a Twinkie represents 
the bandwidth available on a 10-Mb Ethernet network, a 10-Gb Ethernet network would be a 
Twinkie roughly 333 feet long and 100 feet tall—now that's a big Twinkie! 


NOTE 


A community-area network (CAN) can be defined as one or more personal 
homes sharing a common networking architecture. 


LAN protocols have changed rapidly, and there have been many winners and losers in the 
battle for the LAN. Standards such as 100VG AnyLAN never were fully adapted, whereas 
other LAN protocols, such as FDDI I|, have had all development halted. Ethernet currently 
dominates the vast majority of the market share, with some estimates putting it at more 
than 90 percent. Although Token Ring networks are not nearly as plentiful as Ethernet 
Networks, they still are found at most major data centers running |BM mainframes. For these 
reasons, this text focuses primarily on Ethernet and Token Ring LANs and switching. 
Specifically, we will discuss Ethernet and Token Ring LANs, and the configuration of Catalyst 
4000/5500/6500, Catalyst 2900XL/3500, and Catalyst 2900 families of switches. 
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Ethernet LANs 
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Ethernet: A Brief History of an Evolutionary Protocol 


Ethernet's history is colorful. Its conception occurred at the Xerox Palo Alto Research Center (PARC), 
developed by Bob Metcalfe in 1972. In 1979, Digital Equipment Corp., Intel, and Xerox standardized the 
DIX V1.0 frame; two years later, they refined it with the Version 2.0 frame. In 1981, the Institute of 
Electrical and Electronic Engineers (IEEE) project 802 decided to form the 802.3 subcommittee, which is 
almost synonymous with the Ethernet that we know today. Table 2-1 provides a great description of the 
evolution of the Ethernet standard; this standard can be found in its original form in Switched, Fast, and 
Gigabit Ethernet, 3rd edition, by Robert Breyer and Sean Riley. 


Breyer and Riley refer to Ethernet as an evolutionary protocol versus a revolutionary protocol. Evolutionary 
innovations build on the current installed base and provide some form of migration path. As a revolutionary 
protocol, it will have some form of radical breakthrough that usually does not build on the current 
infrastructure. Ethernet is more than 25 years old and still is building a clear future for local-area networks. 
For further reading on the history of Ethernet, the 100-Mbps wars, and Gigabit Ethernet standards, see 
Switched, Fast, and Gigabit Ethernet, 3rd edition, by Robert Breyer and Sean Riley. 


NOTE 


The IEEE name convention works in the following manner. In the name 10Base-T, the 10 
indicates the transmission speed in megabytes per second. The Base indicates baseband 
transmission. The T stands for unshielded twisted-pair cable, while F stands for "fiber." Early 
versions of Ethernet used a number to indicate cable segment length, such as 10Base-5 and 
10Base-2, but this naming convention had to be dropped because of Ethernet's capability to 
have multiple cable lengths running on the same standard. 


Table 2-1. Evolution of the Ethernet Standard 


Colloquial Official 


Ethernet Ethernet IEEE Spec. | Speed i Medium 

Standard Abbreviation | Supplement |(Mbps) | Topology! Meters | Support 

Thick Ethernet |10Base-5 802.3 10 50-ohm 

Mbps coaxial 

(thick) 

Thin Ethernet/ |10Base-2 802.3a 10 Bus 185 m 

Thinnet Mbps coaxial 
(thin) 


Broadband 10Broad- 36 802.3b 10 Bus 1800 m 75-ohm 


Ethernet Mbps coaxial 

10-Mbps Repeaters 802.3c 10 Bus — 50-ohm 

Repeaters Mbps coaxial 
(thick/ 
thin) 


Fiber- optic 
Inter-Repeater 
Link 


802.3d 10 Star 1000 m___|Optical 
Mbps fiber 
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802.3e 


1Base-5 802. 3f 
Layer 802.3h 
Management 
Twisted- Pair 10Base-T 802. 3i 
Ethernet 


Fiber Ethernet a 802. 3) 


Layer 802.3k 
Management 

for 10-Mbps 

Repeaters 

10Base-T 10Base-T 802.31 
Protocol PICS 

Implementation 

Conformance 

Statement 

PICS) 

Second 802.3m 
Maintenance 

Ballot 

Third 802.3n 
Maintenance 

Ballot 


Layer 802.3p 


Management 

for MAUs 

Guidelines for 802.3q 

Development of 

Managed 

Objects 

(GDMO) 

10Base-5 PICS /10Base-5 802.3r 10 
PICS Mbps 

Fourth 802.35 10 

Mbps 


Multimode 


Maintenance 
Ballot 
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120-Ohm 
Cables for 
10Base-T 


802. 3t 
100Base-TX |802.3u 
100Base-T4 /|802.3u 


Fast Ethernet 100Base-FX 802.3u 
over Fiber 


802.3v 
Enhanced MAC |BLAM 802.3w 
or Binary 

Logarithmic 

Arbitration 

Method 


Full- Duplex/ FDX 802.3x 
Flow Control 


Fast Ethernet 100Base-T2 802.3y 
over Two-Pair 
Cat 3 


Gigabit 1000Base-SX |802.3z 
Ethernet Short 
Haul 


Fast Ethernet 


Fast Ethernet 
over Cat 3 


Gigabit 1000Base-LX /|802.3z 
Ethernet Long 

Haul 

Gigabit 1000Base-CX |802.3z 
Ethernet 

Fifth 100Base-T 802.3aa 


Maintenance 
Ballot 


Gigabit 1000Base-T 802.3ab Star 100 m Cat 5 UTP 
Ethernet for 
Cat 5 Cat 5e 


VLAN 802.3ac 


Link 802.3ad 
aggregation 


10000Base 802.3ae Star 100 m-300 |Multimode 
m fiber 
2 km-40 Single- 
km mode fiber 


VLAN tagging |802.1Q — = = 
Secure VLANs {802.10 — = = 


VLAN Frame 
Extension 
Trunking 


VLAN Tagging 


Secure Data 
Exchange SDE 


Traffic 
Expediting 


MAC Bridges, MAC bridges |802.1D — — — — 
Spanning Tree 


[“] 802. ae is not in its final form, but the drafts indicate these operating specifications 


Priority 802.1p — — _ 
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Ethernet Technical Overview 


Ethernet is extremely popular, and many fine books and whitepapers have been written on it. 
For these reasons, we assume that you have some background in Ethernet technology; 
therefore, this chapter does not cover Ethernet frames, hubs, and cables in any great length. 
You should become familiar with the different Ethernet frame types, DIX Version II, and 
802.2 frames, as well as the different media types used in Ethernet. This chapter instead 
focuses more on Spanning Tree, Fast Ethernet, Gigabit Ethernet, and Ethernet and Token 
Ring switching. 


Ethernet Operation 


Ethernet operates at the OSI Layer 2, the data link layer. The data link layer actually is 
divided into two sublayers: the MAC layer and the Logical Link Control (LLC) layer. The LLC 
layer—802.2, in this case—is a standardized interface between a hardware- specific MAC and 
a Layer 3 protocol. 


The MAC layer has the following responsibilities: 


e Generating the physical source and destination address for a frame. These are 48-bit 
industry-wide unique addresses; the first 3 bytes are assigned by the IEEE, and the 
last 3 bytes are vendor-unique. 

Ensuring reliable transmissions. 

Synchronizing data transmissions. 

Performing error recognition. 

Performing flow control. 


Table 2-2 lists the common physical characteristics of 10-Mbps, 10-Mbps, and 1000-Mbps 
Ethernet. 


Table 2-2. Common Ethernet Specifications 


| Specification | 10-Mbps) | 10-Mbps) | 100-Mbps | 100-Mbps | 1000-Mbps | 1000-Mbps 
Minimum frame 512 bits/64 bytes {512 bits/64 4096 bits/512 
bytes bytes 
Peni | time ( ee ae | aan (ee maar 
Maximum a vee S 
trip delay a s) H 


457 milleseconds |3661 
milleseconds 


Maximum network |Approximately 
diameter, with no /|45710 
repeaters (meters) |milleseconds 
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Maximum number /Approximately 5 1 Class | 
of repeaters ina repeater or 2 


collision domain Class II 
repeaters 


Ethernet CSMA/CD 


Ethernet technology commonly is referred to as carrier-sense multiple access collision detect 
(CSMA/CD). Ethernet transmits frames in the following manner: 


1. Carrier sense— This also is known as "listen before talking." An Ethernet station 
wanting to transmit a frame listens to the medium before it transmits to ensure that 
the medium is available. 


2. Talk if quiet— If the channel is quiet for a specific amount of time, the interframe 
gap (IFG) before the station might begin a transmission. If the channel is busy, it is 
monitored until it becomes free for the length of IFG timer; after that time, 
transmission might begin. 


3. Collision— A collision is measured as an excess of voltage on the "cable" or medium. 
A collision usually is caused by two stations transmitting data at the same time. If a 
collision occurs, both frames are destroyed. 


4. Collision detection— If a station detects a collision during transmission, that 
transmission immediately stops. A signal jam also is sent on the media to destroy any 
fragmented frames, preventing corrupted data. 


5. Backoff— After a collision, a stations waits a period of time called the backoff period. 
The backoff timer is a random timer generated by a backoff algorithm. This prevents 
all stations from trying to transmit at the exact same time after a collision. After the 
backoff timer expires, the station attempts to retransmit the frame. If another 
collision happens, the station keeps trying to retransmit the frame for 16 times. After 
16 unsuccessful attempts, the frame is dropped. 


Half- and Full-Duplex Ethernet 


Ethernet was developed on older coax type cables capable of transmitting or receiving a 
signal at any given time. This is precisely why Ethernet needed CSMA/CD technology. With 
the advent of switches, running Ethernet over UTP and fiber, full-duplex Ethernet became 
available. Full-duplex Ethernet allows a station to simultaneously transmit and receive data. 
Ethernet frames are transmitted and received simultaneously on two pairs of UTP or fiber at 
any given time. Full-duplex Ethernet is essentially Ethernet without CSMA/CD. Full-duplex 
mode basically doubles the bandwidth of Ethernet! To run full-duplex Ethernet, the station 
and switch both must be capable and configured for full-duplex operation. A hub with 
multiple stations cannot operate in full-duplex mode. 


NOTE 


A station not operating in the correct duplex mode will generate an enormous 
number of collisions on the port where it is located. These collisions mostly likely 
will be registered as "late collisions." Be sure that the port on the switch and the 
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end station are operating in the same duplex mode. 


Fast Ethernet 


In May 1995, the IEEE adopted the Fast Ethernet standard, 802.3u. Years later, after battling 
FDDI, 100VG AnyLAN, and ATM, this standard became the prominent type of LAN. As costs 
per port dropped along with the prices of network interface cards (NICs), Fast Ethernet won 
out over FDDI and 100VG AnyLAN and ATM for many reasons: 


e It allows a clean and inexpensive migration path from existing 10-Mbps Ethernet 
networks. At first, it could run only fiber and Cat 5 UTP, but as Table 2-1 indicates, it 
now can run over almost every media type. 

e Fast Ethernet didn't require costly fiber connections and didn't require complex 
configurations. 

e Fast Ethernet addresses QoS with enormous amounts of bandwidth, while relying on 
the upper layers or network design to provide QoS. 

e Basically, Fast Ethernet became a plug-and-play tenfold upgrade of the LAN. 100-Mb 
networks evolved out of 10-Mb networks across data centers everywhere. 


Some important features and specifications of Fast Ethernet are as follows: 


e The 100Base MAC uses the original Ethernet MAC operating at 10 times the speed. 
This is completely backward compatible with 10-Mbps Ethernet. 

e 100Base-T includes a specification for an MII interface. A MII interface is a 100-Mbps 

version of the AUI adapter. 

Fast Ethernet supports full- and half-duplex functionality. 

Fast Ethernet operates over a wide array of different physical layers: Cat 5, Cat 3, 

fiber, and so on, as listed in Table 1-2. 


Gigabit Ethernet 


The ink was hardly dry on the Fast Ethernet standard, and the |EEE started to work on the 
802.3z, or Gigabit Ethernet, standard. Three short years later, in J une 1998, the 802.3z 
standard officially was adopted. For the most part, the Gigabit standard is the Fast Ethernet 
standard multiplied by 10. This is why 10-Gb Ethernet products are right around the corner 
and 100-Gb Ethernet is an eventuality. 


Some important features and specifications of Gigabit Ethernet are as follows: 


e Gigabit Ethernet uses the 802.3 frame format, identical to that of 10-Mbps and 100- 
Mbps Ethernet. 

e It includes a specification for a Gigabit MII (GMII). Unlike 10-Mbps Ethernet and 100- 
Mbps Ethernet, the GMII is an electrical specification and does not include a physical 
connector. Cisco's physical Gigabit interfaces are called GBICs. The type of GBIC 
determines the physical gigabit connection. There are currently multimode fiber 
(MMF), single-mode fiber (SMF), and UTP GBICs, as well as a Cisco proprietary GBIC 
called a Gigastack. 


One element that makes Gigabit Ethernet one of the most versatile protocols in years is the 
concept of the GMII. Except for the strictly LOOOBase-TX switches, most Gigabit Ethernet 
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switches come with open ports for GBICs. Depending on your network needs, you can put 
any type of GBIC in this port. With the click of a GBIC, your network can change from a 
limited 100-m copper-based network to a 10,000-m fiber-based network! The sections that 
follow cover the more common GBICs, Gigabit standards, and length limitations. 


1000Base-SX Gigabit Ethernet 


1000Base-SX GBICs use a laser-based wavelength of 850 nms. Depending on the cable type, 
SX GBIC operates at distances of 220 m to 550 m, as listed in Table 2-3. Wavelengths up to 
850 nm are visible to the human eye. 


Table 2-3. 1OOOBase-SX Cable Limitations 


| Standard | Cable Size (Microns) | Max. Distance (m) 


1000Base-SX 62.5-um multimode fiber 275M 


1000Base-SX 50-um multimode fiber 550m 


1000 Base-LX Gigabit Ethernet 


LX GBICs use a laser-based wavelength of 1300 nms. Depending on the cable type, LX GBIC 
operate at distances of 550 m to 5000 m, as listed in Table 2-4. Cisco also supports an LH 


and LX GBIC, which extends the IEEE 1000Base-LX maximum distance of 5 km. 


Table 2-4. 1OOOBase-LX Cable Limitations 


| Standard | Cable Size (Microns) | Max. Distance (m) 


1000Base-LX 62.5-um multimode fiber 550m 


/1000Base-LX [50-um multimode fiber [550 m 
/1000Base-LX [9/10-um single-mode fiber [5 km 


1000Base-LH 50-um multimode fiber 


1000Base-LH [9/10-um single-mode fiber 10 km 
1000Base- ZX [9/10-um single mode fiber [70 km 


1000Base- ZX 9/10 Disposition-shifted fiber 100 km 


1000Base-CX Gigabit Ethernet 


The CX standard is for operating Gigabit Ethernet over copper for short distances. 1000Base- 
CX uses a 150-ohm balanced shielded copper cable. The distance of the CX standard is 
limited to only 25 meters. 


1000Base-T Gigabit Ethernet 
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The |EEE standard for Gigabit Ethernet transmission over Cat 5 UTP is 802.3ab. The standard 
defines the maximum distance to be 100 meters and the copper to be at least Cat 5 using 
four pairs of wires, terminated with an RJ-45 jack. Figure 2-1 illustrates a GBIC. 


Figure 2-1. GBIC Installation 


GBIC 


Squeeze in clips 
and slide GBIC 
into slot 


NOTE 


The Cisco Gigastack GBIC is a Cisco proprietary GBIC used on an uplink port to 
connect Gigabit Ethernet switches. 


Ethernet Autonegotiation 


To simplify the configuration of Ethernet devices, the 802.3.u committee defined Fast Link 
Pulse (FLP). FLP sends a series of pulses on the network that can deduce what duplex and 
speed the link is operating at. The station and the hub/switch agree on the highest priority 
and configure the station in that manner. Table 2-5 lists the priority that FLP uses. Both 


devices need to support autonegotiation logic for autonegotiation to work. 


Table 2-5. Ethernet Autonegotiation Prioritization ve 


Speed and Duplex Settings 
100Base-T2 full duplex 


2 ——__: [100Base-T2 half duplex 
3 100Base-TX full duplex 
4 [L00Base-T4 half duplex 

[5 [100Base-TX half duplex 

6 [10Base-T full duplex 

\7 |10Base-T half duplex 


[“] The priority of 1 eventually might be replaced by 1000Base-T full-duplex, 
shifting the others down by one. 


Priority 


Infrastructure devices, such as routers and servers, always should have speed and duplex 
settings fixed. Most 100-Mbps and greater NICs support full-duplex operation. Running at full- 
duplex mode essentially doubles the capacity of Ethernet. Taking advantage of this is the 
cheapest network upgrade that you will ever do! 


NOTE 


Duplex modes are a function of the hardware built into the network interface 
card (NIC). Software upgrades will not allow you to run full-duplex mode. For 
full-duplex mode to work, the station and the switch port must be capable of full- 


duplex operation. 
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802.1d Spanning-Tree Protocol (STP) 


When Ethernet evolved from a single shared cable to networks with multiple bridges and 
hubs, a loop-detection and loop-prevention protocol was needed. The 802.1d protocol, 
developed by Radia Perlman, provided this loop protection. It did such a good job that when 
most networks went from bridged networks to routed networks, so the importance of 
Spanning Tree was almost forgotten. Because of this, Spanning Tree is probably the most 
used but least understood protocol in the modern internetwork. But with the huge success of 
Ethernet switching, Spanning Tree again becomes an important protocol to control and, more 
importantly, understand. We will discuss why Spanning Tree has become so important in 
switched Ethernet networks in upcoming sections. 


Spanning Tree Operation 


Spanning Tree's purpose in life is to elect a root bridge and build loop-free paths leading 
toward that root bridge for all bridges in the network. When Spanning Tree is converged, 
every bridge in the network has its bridged interfaces in one of two states: forwarding or 
blocking. If the port has the best-cost path to the root bridge, it is forwarding and thus is the 
shortest path to root. All other interfaces on the bridge are in a blocking state. STP 
accomplishes this by transmitting special messages called Bridge Protocol Data Units 
(BPDUs). BPDUs exist in two forms: 


e Aconfiguration BPDU, used for initial STP configuration 
e A Topology Change Notification (TCN) BPDU used for topology changes 


BPDUs are transmitted using a reserved multicast address assigned to all bridges. The BPDU 
is sent out all bridged LAN ports and is received by all bridges residing on the LAN. The BPDU 
is not forwarded off the LAN by a router. The BPDU contains the following relevant 
information: 


e Root 1 D— The !D of the bridge assumed to be root. Upon initialization, the bridge 
assumes that it is root. 


e Transmitting bridge 1D and port | D— The BID of the bridge transmitting the 
BPDU, and what port the BPDU originated from. 


e Cost to root— The least-cost path to the root bridge from the bridge transmitting the 
BPDU. Upon initialization, because the bridge assumes itself to be root, it transmits a 
0 for the cost to root. 


The bridge ID (BID) is an 8-byte field composed from a 6-byte MAC address and a 2-byte 
bridge priority. The MAC address used for the BID is generated from a number of sources, 
depending on the hardware in use for the bridge. Routers use a physical address, whereas 
switches will use an address from the backplane or supervisor module. Figure 2-2 illustrates 


the BID. The priority value ranges from 0 to 65,535; the default value is 32,768. 


Figure 2-2. The BID 
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BID - 8 bytes 


2 bytes 6 bytes 
Range:  0-65,535 from 
Default! 32,768 Backplane/Superviser 


The path cost is used by bridges to determine the best possible path to root. Path costs 
recently have been updated by the IEEE to include Gigabit and greater links. The lower the 
path cost is, the more preferable the path is. Table 2-6 lists the STP cost values for LAN links. 


Table 2-6. STP Cost Values for LAN Links 


| Bandwidth STP Cost 


4 Mbps 250 
10 Mbps 100 
16 Mbps 62 


45 Mbps 


B90 
100Mbps  s—its—‘—SC 100Mbps  s—its—‘—SC pe 
155 Mbps 14 
622 eels 


1 Gbps! 
10 Gbps 


N 


["] Before the IEEE standard was updated, the lowest value that STP could 
attain was 1. An STP cost of 1 was used for all links greater than or equal to 1 
Gb. 


STP has five primary states that it transitions through during its operation. When STP 
converges, it is in one of two states, forwarding or blocking. Table 2-7 lists the states of STP. 


Table 2-7. Various STP States 


148 


User Data Being 
STP State STP Activity Passed 


Port is not active; it is not participating |No 
in any STP activity. 

The 802.1q trunk is misconfigured on No 
one end, or the default/native VLANs do 

not match on each end. 


Port is sending and receiving BPDUs. No 
Learning IA loop-free bridging table is being built. |No 
Forwarding |User data is being sent and received. Yes 
Blocking User traffic is not permitted out the No 
port. 


PortFaste=! lListening/learning states. Yes 


["] portFast is a Cisco-specific states that allow user data traffic to be 
forwarded during the STP convergence process. 


The ports transition from one state to another, as depicted in Figure 2-3. 


Figure 2-3. The STP Transition 
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Blocking Blocking state 


Listening state Disabled state > 


Blocking 


15 seconds 
(Default) 


Laarning state 


15 seconds 
(Default) 


Forwarding 
state 
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Let's examine each of these states in more detail. 
Disabled 


This state appears when a bridge is having problems processing BPDUs, when a trunk is 
improperly configured, or when the port is administratively down. 


Listening 


When a bridge port initializes or during the absence of BPDUs for a certain amount of time, 
STP transitions to the listening state. When STP is in this state, the port is actually blocking 
and no user data is sent on the link. STP follows a three-step process for convergence: 


1. Elect one root bridge— Upon initialization, the bridge begins sending BPDUs on all 
interfaces. A root bridge is chosen based on the bridge with the lowest BID. Recall 
that the BID is a combination of a priority and MAC address. In the event of a tie, the 
bridge with the lowest MAC address is chosen as root. All ports of the root bridge are 
put in the forwarding state. 


2. Elect one root port for every nonroot bridge— After a single root bridge has been 
elected, STP elects a single root port on each bridge that is not root. The root port is 
the bridge's best path to the root bridge. When a root port is elected, it is put into the 
forwarding state. To determine what port should be a root port, STP follows this 
decision process: 


a. Lowest root BID 

b. Lowest path cost to root bridge; the cumulative cost of the all paths to root 
c. Lowest sender BID 

d. Lowest port ID 


When a bridge receives a BPDU, it stores it in a bridge table for that port. As new 
BPDUs are received on that port, they are compared to existing BPDUs. Using the four- 
step process listed previously, BPDUs that are more attractive or that have lower 

costs are kept, and the other ones are discarded. The primary variable that influences 
the root port election is the cost to the root bridge. This is the cumulative path cost of 
all links to the root bridge. 


3. Elect one designated port/ designated bridge for every segment— For every 
segment, STP elects one port that will send and receive all information from that 
segment to the root bridge. A root port can be thought of as the port that forwards 
information to the root, whereas the designated port can be thought of as the port 
that sends traffic away from the root. This rule applies mostly to shared-media 
bridges, or routers. Designated ports on back-to-back switched trunk lines do not 
follow this rule. 


4. All remaining ports become nondesignated ports and are put in blocking 
mode. 
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Learning 


Ports that remain designated or root ports for a period of 15 seconds, the default forward 
delay, enter the learning state. The learning state is another 15 seconds that the bridge waits 
while it builds its bridge table. 


Forwarding and Blocking 


When the bridge reaches this phase, ports that do not serve a special purpose, such as a root 
port or a designated port, are called nondesignated ports. All designated ports are put in a 
forwarding state, while all nondesignated ports are put into a blocking state. In the blocking 
state, a bridge does not send any configuration BPDUs, but it still listens to them. A blocking 
port also does not forward any user data. 


Figure 2-4 illustrates a basic configuration, with the appropriate ports marked. 


Figure 2-4. STP Ports and Roles 


Segment 2 


Segment 1 


1i2 
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STP Timers 


STP has three basic timers that regulate and age BPDUs: a hello timer, a forward delay timer, 
and a max age time. The timers accomplish the following for STP: 


Tae 


e Hello timer— The default hello timer is 2 seconds. This is the amount of time 
between configuration BPDUs sent by the root bridge. 


e Forward delay timer— This timer is the default 15 seconds that the routers wait 
while building its bridging table. The listening and learning stages each use this single 
15-second timer. 


e Max age timer— The max age timer is how long a BPDU is stored before it is 
flushed. If this timer expires before the interface receives a new BPDU, the interface 
transitions to the listening state. An expired max ageparameter usually is caused by a 
link failure. The default value is 20 seconds. 


STP uses the hello timer to space BPDUs and has a keepalive mechanism. The hello timer 
always should prevent the MAX age value from being hit. When the max agetimer expires, it 
usually indicates a link failure. When this happens, the bridge re-enters the listening state. 
For STP to recover from a link failure, it takes approximately 50 seconds; it takes 20 seconds 
for the BPDU to age out, the max age; and it takes 15 seconds for the listening state and 15 
seconds for the learning state. 


NOTE 


Two other forms of STP exist besides IEEE 802.1d. DEC and IBM are two other 
forms of Spanning Tree in use. The operation of all forms of STP is similar, and 
Cisco routers support all forms. 


By now, you might be asking yourself, how could a protocol like this play a role in the 
modern network, with a Layer 2 protocol, 2-second hellos, and a 50-second convergence 
time? Because a switch is a Layer 2 device, all VLANs use Spanning Tree to build loop-free 
paths between switches. Cisco implements Per VLAN Spanning Tree (PVST). With PVST, there 
is one instance of Spanning Tree running in every VLAN. Now, take a modern network with 
50 VLANs, that's 50 instances of Spanning Tree running on every trunk and every switch! 
Quickly, the need to understand and control this protocol becomes evident. Because this is so 
important, controlling Spanning Tree is one of major focuses of the section, "Configuring 


Catalyst Ethernet Switches." 
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Ethernet Switching 


In the early 1990s, Kalpana, Grand Junction, and Bay Networks started to ship some of the first Ethernet switches. The Bay Networks 28115 was 
one of the first switches to introduce 10/100 auto-sensing ports and virtual LANs (VLANS). More importantly, all switches put an end to the old 
Ethernet repeater rules, while increasing bandwidth. Until this point, many people were predicting that ATM would be the only high-speed protocol 
in use on the LAN—and if it hadn't been for the Ethernet switch, they might have been right. 


Ethernet switches provide several key advantages over traditional shared media LANs: 


Significant bandwidth improvement by limiting a collision domain to a single port. 

Scalability. Repeater rules are limited to a single port. 

VLAN capability. Broadcast domains can be located logically and are not limited by geographical boundaries. 
Enhanced security. 

Full-duplex capability. 


A switch functions much like a multiport bridge. When VLANs are created, virtual bridges are created to join the ports in the VLAN. Broadcast, 
unicast, and multicast traffic is forwarded to each member of the VLAN. The Catalyst 5500 series switch builds an address table by recording the 
source MAC address of frames that it received from its interfaces. When a frame destined for an address not yet in the address table is received, 
the switch floods the frame out all ports and trunks in the same VLAN as the frame was received. The switch does not forward the frame out the 
interface that it received it. When a reply for that frame is received, the switch records the new address in the address table. The switch forwards 
subsequent frames to a single port, without flooding it to all ports. Traffic can leave the VLAN only with the aid of a router or a Layer 3 switch 
providing routing functionality. 


Switches forward traffic in three primary modes: 


e Store-and-forward— The port adapter reads the entire frame into memory and then determines whether the frame should be forwarded. 
The frame is forwarded only if it does not contain any errors. Store-and-forward mode reduces the amount of errors on the LAN, but there is 
a delay associated with reading and verifying the frame before forwarding it. ln modern ASIC-based switches, the speed of the ASIC has 
become so great that the latency associated with store-and-forward switches is a nonissue. 


e Cut-through— In this mode, the port receives the first few bytes of a frame and analyzes the packet header to determine the destination 
of the frame and immediately begins to forward that frame. The frame is not checked for any errors before forwarding, so this mode does 
propagate bad frames on the network. 


e Adaptive cut-through— This mode combines both aspects of cut-through and store-and-forward modes. In this mode, the port operates 
in cut-through mode until a user-defined threshold of frame errors is detected. When the threshold is exceeded, the port switches to store- 
and-forward mode. ay 


Broadcast Domains and Collision Domains 


Two key concepts in switched networks are broadcast domains and collision domains. A broadcast domain is the area of the network that forwards 
broadcasts from one portion of network to the next. A practical example of a broadcast domain is an IP or IPX subnet. A collision domain is a 
function of the physical properties of a device. Devices in the same collision domain reside on the same "wire" or hub/repeater. Table 2-8 illustrates 


how various network devices segment collision and broadcast domains. 


Figure 2-5 illustrates where collision and broadcast domains reside on various devices 


Figure 2-5. Collision and Broadcast Domains 
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Table 2-8. How Various Network Devices Segment Collision and Broadcast Domains 
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Hardware 

Type Collision Domain Broadcast Domain 

Hub/ repeater All ports are in a single collision All ports are in a single broadcast domain. 
domain. 

Bridge Each port is a separate collision All ports are in a single broadcast domain. 
domain. 

pene Fe port is a separate collision ach port is in a separate broadcast domain.-! 

omain. 


Switch Each port is a separate collision Each port is configurable to be in the same or a separate 
domain. collision domain. 


(*] Assuming that bridging is disabled 


Virtual LANs (VLANS) 


Many definitions for a VLAN exist. The definition that we chose to use is simple. Virtual LANS (VLANs) can be easily defined as broadcast domains 
that can extend geographical distances. When configuring Ethernet switching, every port must be assigned to a VLAN. The default VLAN is always 
VLAN 1. When switches ship from the factory, they are in some ways plug-and-play. Every port is assigned to VLAN 1, so every port of the switch is 
in a single broadcast domain. This makes migrating from shared Ethernet hubs to a basic switched network easy. VLANs always should be thought 
of as simply broadcast domains. Most VLANs eventually become |P/IPX subnets or bridging domains. The basic design rules that apply to broadcast 
domains also apply to VLANs: 


A single subnet is used per VLAN. 

Do not bridge different VLANs together. 

A router/Layer 3 switch is needed to route between VLANs. 

STP must run in each VLAN to prevent loops. This can be disabled, but it is not recommend. 


Let's examine some basic switched networks, focusing on the differences in each one. 


Figure 2-6 shows a basic VLAN configuration. The switch has VLANs 1 and 2 configured on it. Each VLAN is configured with a separate IP subnet. If 
information needs to pass from VLAN 1 to VLAN 2, a router is required. Here, the router has an interface in each VLAN. Traffic going from one VLAN 
to the other needs to first hit the router. The downfall in this configuration is that a single interface is required for every VLAN that needs to be 
routed, severely limiting the scalability of networks like this. 
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Figure 2-6. Per Interface VLAN Routing 
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Figure 2-7 shows another basic VLAN configuration. The switch has VLANs 1 and 2 configured on it again. Here, the router has a single 100-Mbps 


interface running a VLAN trunking protocol, such as 802.1q. Traffic going from one VLAN to the other must travel up the trunk to the router and 
then back down the same trunk. Using a single trunk to route between VLANs is the most economical way to accomplish routing between VLANs. 
This type of configuration often is referred to as a "router on a stick." 
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Figure 2-7. Router on a Stick 
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The next evolution was to move the routing function from a standalone router to the switch itself; this is called Layer 3 switching. This move was 
only logical because traffic is doubled up coming in and exiting the same router interface. At first, this was accomplished through the use of a route 


switch processor (RSM), installed into a Catalyst 5500 series switch. More switches now are offering this capability. Figure 2-8 illustrates a Layer 3 
switch. 
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Figure 2-8. Layer 3 Switching 
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VTP and Trunking Protocols 


A powerful function of VLANs is their capability to span distance. VLANs are communicated from switch to switch by the means of a VLAN Trunking 
Protocol (VTP). VTP is used to maintain global VLAN information between switches. A VLAN management domain, or VTP domain, consists of one or 
more switches interconnected and sharing the same administrative responsibility. Anytime that you want the VLANS on one switch to have 
information about the VLANs on another switch (that is, when you want these two broadcast domains to communicate), you need to configure a 
VTP domain and a trunk. VTP also tracks all the VLANs in a VTP domain and propagates these in a client/server manner from one switch to another. 
The intent of VTP is to ease management and provide a common VLAN database across the VTP domain. 


VTP advertisements are sent out on all trunk connections in Inter-Switch Link (ISL) frames, 802.1q frames, IEEE 802.10, or ATM LANE. VTP frames 
are sent to the destination MAC address of 0100.0ccc.ccc with an LLC code of SNAP (AAAA) and a type of 2003 in the SNAP header. For VTP 
messages to successfully be transmitted, the following must occur: 


e VTP will accept only messages with the same domain name. If authentication is configured for that VTP domain, that, too, must match. The 
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After a 


VTP name is case-sensitive. 

VTP will accept only messages with the same version, Type | or Type II. This setting is controlled, with the V2 mode being either enabled on 
both sides of the link or disabled. A switch might be VTP version I|-capable and have V2 mode disabled. V2 mode is primarily for Token 
Ring switches. 

Catalyst switches must be adjacent, and trunking must be configured between them. For Ethernet networks, the trunking protocol is dotq1 
(802.1q) or ISL. ATM uses LANE, and FDDI uses IEEE 802.10. 

VTP servers will synchronize with VTP clients only if the VTP client's revision number is less than that of the VTP server. If the VTP client's 
revision number is equal to or greater than that of the VTP servers the client VLAN database will not synchronize. 


trunk is established, VTP sends periodic advertisement out each trunk port. The VTP advertisements contain the following: 


VLAN IDs (ISL and 802q). 

Emulated LAN names for ATM LANE. 

802.10 SAID values. 

VTP domain name and configuration revision number. The server with the highest revision number becomes the primary server. The 
revision number is incremented every time a VLAN configuration change is made. 

VLAN configuration, VLAN ID, VLAN name, and MTU size for each VLAN. 

Ethernet frame format. 


VTP has two versions, simply called version | and version II. All the switches in the VTP domain must be on the same version. This rule does not 
apply to the transparent-mode switches. Version II offers the following, the most important being support for Token Ring: 


Token Ring support— VTP VII supports Token Ring LAN switching and VLANs (Token Ring Bridge Relay Function [TrBRF]). We will discuss 
TrBRF more in upcoming sections. 


Unrecognized type— Length value (TLV) support is included. Unrecognized TLV is saved in NVRAM when the switch is in VTP server mode. 


Version-dependent transparent mode— VTP will forward VTP messages that do not match the domain name and version to switches 
operating in VTP transparent mode. 


Consistency checks— Consistency checks are performed on VLAN names, and values are performed only upon new entry into the switch. 


VTP operates in one of three modes: 


e VTP server mode— In VTP server mode, VLANs can be created, modified, and deleted. VLAN information automatically is sent to all 


adjacent VTP servers and clients in the same VTP domain. Caution always should be used when "clearing" a VLAN from the VTP server 
because that VLAN will be deleted on all VTP servers and clients in that DTP domain. If two devices are configured as servers, the switch/ 
server with the highest VTP configuration revision will be the primary server. VLAN information is stored in the switches NVRAM. 
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e VTP client mode— In VTP client mode, VLANs cannot be created, modified, or deleted. Only the name and the VTP mode and pruning can 
be changed. The client is at the mercy of the VTP server for all VLAN information. The client still must assign ports to a VLAN, but the VLAN 
will not be active on the switch unless the VTP server sends information to the client on that VLAN. Furthermore, VLAN information is stored 
locally in the switch's NVRAM when it is received from the server on the Catalyst 2900XL/2500G series switches. The Catalyst 
4000/5500/6500 series of switches do not store the VLAN database if configured has a VTP client. 


e VTP transparent mode— In VTP transparent mode, VTP information that is local on the switch will not be advertised, but VTP information 
received form other switches will be forwarded. VLANs can be created, modified, and deleted on transparent switches. VLAN information 
also is stored in NVRAM. Table 2-9 highlights the various modes and operation. 


Table 2-9. Various VTP Modes of Operation 


Create, 
Source VTP Propagate Local VTP Listen to VTP Modify, and 
VTP Mode Messages Information Messages Delete VLANs 


‘Server Yes Yes Yes Yes 
i Y 


es — 
Transparent |),(**1 No 


VLAN Database 
Saved Locally 


[“] The Catalyst 4000/5500/6500 series of switches do not store the VLAN database on VTP client switches. The Catalyst 
2900XL/3500G series of switches do save this information and have the VLAN database upon initialization. 


*]n transparent mode, the switch does not participate in VTP. That is, it does not synchronize VTP databases. However, VTP 
information still is received and sent out other trunk ports. Local VLAN information is not propagated by the trunks. 


Table 2-10 lists the default VTP mode on Catalyst switches. 


Table 2-10. Default VTP Settings 


| VTP Feature | Default Setting 162 | 


Disabled 
VTP security/ password Disabled 


VLAN Trunking Protocols 


VTP requires trunks to transport VTP information. A trunk is considered a point-to-point link between Ethernet switch ports and another networking 
device such as a router or another switch. Trunks have the capability to carry the traffic of multiple VLANs over a single link and extend VLANs 
across the internetwork. Without the use of VTP and trunks, an IP subnet could never be partitioned across switches. VTP trunks allow for an 
effective way to tie two broadcast domains together. Figure 2-9 illustrates how 802.1q trunks are used to tie VLANs 4 and 2 together. 


Figure 2-9. VLAN Trunking 
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Three primary trunking encapsulations are available for Ethernet: 
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e Inter-Switch Link (I1SL)— ISL is a Cisco proprietary trunking encapsulation. ISL is a frame-tagging protocol; the frames on the link 
contain the standard Ethernet, FDDI, or Token Ring frame and the VLAN information associated with that frame. ISL is supported on links 
that are 100 Mbps or greater in speed. ISL is an extremely efficient protocol, and it is the protocol that Cisco uses internally for Catalyst to 
communicate with the route switch modules (RSMs) or other Layer 3 switching fabric. Spanning Tree is run on a per-VLAN basis (PVST) on 
ISL trunks. This means that every VLAN has a root bridge, and trunks go into a forward/blocking mode for each VLAN on each trunk. PVST 
is critical to control on large networks, as discussed in upcoming sections. 


e IEEE 802.1q— 802.1q is the industry-standard trunking protocol. 802.1q operates slightly differently than ISL. It runs Mono Spanning Tree 
(MST) on the default VLAN for all VLANs in the VTP domain. In MST, one root bridge is elected for the entire VTP domain; this is called the 
Common Spanning Tree (CST). All VLAN information follows one path in this type of configuration. Cisco, understanding the need to control 
Spanning Tree on large networks while controlling load, implements PVST on all 802.1q VLANs. The following is a list of other restrictions on 
802.1q trunks: 


- The default VLAN needs to be the same on both ends of the trunk. MST will run in this VLAN. It is critical that the default VLAN be 
the same on third-party switches interacting with Cisco switches. 


- AS mentioned, 802.1q uses MST. Cisco overrides this, by default, with PVST. Because the BPDUs are handled differently between 
Cisco and third-party switches, care should be taken whenever integrating these domains that Spanning Tree and the default VLANs 
are consistent in both switches. The entire Cisco VTP domain looks like a single broadcast/ spanning tree domain to the third-party 
switches. 


- BPDUs on the native VLAN of the trunk are sent untagged to the reserved IEEE 802.1d Spanning Tree multicast MAC address (0180. 
c200.0000). The BPDUs on all other VLANs on the trunk are sent and tagged on the reserved Cisco Shared Spanning Tree (SSTP) 
multicast MAC address (0100.0ccc.cccd). 
e IEEE 802.10— 802.10 was actually the first protocol that the industry tried to use for a VLAN trunking protocol. It originally was developed 
for extra security on defense networks or large MANs. It primarily is used on FDDI networks today because of its limitations. 


Dynamic ISL (DISL) and Dynamic Trunk Protocol (DTP) 


Dynamic ISL was Cisco's first trunk-negotiation protocol. It exists on all Catalyst 5500 series software 4.1 and earlier. Originally, it was used to 
negotiate trunks for the ISL protocol only. Later, in 4.2, DISL was replaced with Dynamic Trunk Protocol (DTP). DTP is essentially DISL that 
attempts to automate ISL and 802.1q trunk configuration. DTP uses the reserved destination multicast address of 0100.0ccc.cccc for LAN networks 
to negotiate trunks. In the default auto state, DTP messages are sent out every 30 seconds on all trunk lines. Depending on the mode of the port, 
the port might become an ISL or 802.1q trunk. DTP operates in the following modes: 


e On— Puts the port in a permanent trunking state. It also tries to negotiate the link to be a trunk. 


e Off— Disables the port, and thereby the trunk. 
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e Desirable— Makes the port attempt to convert to a trunk link. The port becomes a trunk if the neighboring port is set to on, desirable, or 
auto modes. 


e Auto— The port converts to a trunk if the neighboring port is set to on or desirable modes. 
e Nonegotiate— Puts the port into trunking mode but prevents the port from sending DTP frames. 


In actuality, this is really too many options for a trunk. Network administrators either configure a port as a trunk or they don't. It could be argued 
that to have a network be so flexible the trunks can or should be added dynamically is a security risk. Table 2-11 illustrates the possible 
combinations of trunks and the modes. As you will see, the most reliable and simplest way to configure a trunk is to statically configure it on both 
sides of the link as a trunk and in the "on" mode. 


Table 2-11. Ethernet DTP Configuration Outcomes 


Trunk Mode 

and Trunk 

Encapsulation off on desirable | auto on desirable | auto | desirable auto 
ISL or 

DOT1Q |ISL ISL ISL DOT1Q |DOT1Q DOT1Q (negotiate |negotiate 


Local: Local: ISL |Local: Local: Local: 1Q |Local: Local: Local: Local: 
Nontrunk |trunk Nontrunk Nontrunk {Trunk Nontrunk Nontrunk |Nontrunk Nontrunk 


Neighbor 
Port 


ISL or DOT1Q 


Neighbor: 
Nontrunk 


Neighbor: Neighbor: 
Nontrunk Nontrunk 


Neighbor: |Neighbor: 
Nontrunk |Nontrunk 


Neighbor: 
Nontrunk 


Neighbor: 
Nontrunk 


Neighbor: 
Nontrunk 


Neighbor: 
Nontrunk 


Local: ISL Local: ISL 


Local: 
Nontrunk 


Local: ISL 
trunk 


Local: 1Q |Local: 
trunk Nontrunk 


Local: ISL 
trunk 


Local: ISL 
trunk 


Local: 
Nontrunk 


ISL 


Neighbor: 
Neighbor: ISL 


Nontrunk 


Neighbor: 
ISL trunk 


Neighbor: 
ISL trunk 


Neighbor: 
ISL trunk 


Neighbor: 
ISL trunk 


Neighbor: 
ISL trunk 


Neighbor: 
ISL trunk 
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2 ISL 


Local: ISL 
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Local: ISL 
trunk 


Local: 1Q 
trunk 


Local: ISL 


Local: ISL 


Local: 
Nontrunk 


Local: 
Nontrunk 


Local: 
Nontrunk 


desirable |ISL 


Neighbor: 
Nontrunk 


Neighbor: 
ISL trunk 


Neighbor: 
ISL trunk 


Neighbor: 
ISL trunk 


Neighbor: 
Nontrunk 


Neighbor: 
Nontrunk 


Neighbor: 
Nontrunk 


: ISL jLocal: ISL 


trunk 


Local: 1Q 
trunk 
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Nontrunk Nontrunk Nontrunk 


Local: 
Nontrunk 


Neighbor: 
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Neighbor: 
ISL trunk 


Neighbor: 
Nontrunk 
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Nontrunk Nontrunk Nontrunk 


ISL trunk 


Local: 1Q 
trunk 


Local: 
Nontrunk 


Local: 
Nontrunk 
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1Q trunk 


Neighbor: 
1Q trunk 


Neighbor: 
1Q trunk 


Local: 1Q 
trunk 


Local: 
Nontrunk 


Local: 
Nontrunk 


DOT1Q 


Neighbor: 
Nontrunk 


Neighbor: 
Nontrunk 


Neighbor: 


Local: Local: 


Nontrunk Nontrunk Nontrunk Nontrunk 
Neighbor: Neighbor: Neighbor: Neighbor: 
Nontrunk |Nontrunk |Nontrunk Nontrunk Nontrunk 
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Local: : ISL {Local: ISL : Local: 1Q : ISL |Local: ISL Local: ISL 
Nontrunk trunk trunk 


NEIGHBOR: 
Neighbor: i : |Neighbor: i : |Neighbor: i : i : ISL 
Nontrunk |ISLtrunk |ISL trunk 1Q trunk ISL trunk 


negotiate Local: Local: ISL |Local: ISL : Local: 1Q Local: : Local: 
Nontrunk trunk Nontrunk Nontrunk 


Neighbor: |Neighbor: 
Neighbor: |ISL trunk |ISL trunk i : |Neighbor: i : Neighbor: Neighbor: 
Nontrunk 1Q trunk Nontrunk Nontrunk 


Configuring Catalyst Ethernet Switches 


The colorful history of Ethernet switching is present in the Catalyst line. Each family of Catalyst switches has a slightly different command-line 
interface. The Catalyst switches such as the 1900 and 2800 come from Grand J unction and have one type of configuration interface and method. 
The Catalyst 3000 originated with Kalpana and has another method of configuration. The Catalyst 5500 family started with Cisco's acquisition of 
Crescendo. The Catalyst 5500 and 6500 families have a unique configuration interface originally called the XDI. Presently, the configuration mode is 
simply called the command-line interface (CLI); whereas the Catalyst 8500 series uses a hybrid, where the configuration resembles the traditional 
Cisco router configuration, except that it is a router with hundreds of ports. 


The upcoming sections, excluding the section on Token Ring, focus on configuring the Catalyst 2900XL and 3500G family of switches along with the 
Catalyst 4000/ 5500/6500 series switches. These two families represent that majority of Cisco Catalyst switches in deployment. 


LAN switches were designed to be easy to install and configure. On smaller networks, little to no configuration might be required. On large 
redundant networks, with multiple VLANs and trunks, switching becomes quite a task. Configuring Ethernet switch configuration can be divided into 
a four-step process. Most switches, not all, will require a nondefault VTP domain to be created before VLANs can be created. 


Step 1. Configure switch management. 
Step 2. Configure VTP and VLANs. 
Step 3. Configure VLAN trunks, if applicable. 


Step 4. (Optional) Control STP and VLAN propagation. 
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Step 1 involves configuring the management VLAN, IP addresses, and default gateways on the switch so that it can be accessed in-band from the 
internetwork. 


In Step 2, you define the VTP domain and the VLANs on the VTP servers. During this step, you also assign ports to VLANs. 
Step 3 involves configuring VLAN trunks, if there are any on the network. 


Step 4 is optional but critical to large networks. It involves controlling STP through the setting of root bridges, clearing VLANs from trunks, and 
using VLAN prune eligibility. 


Step 1: Configuring Switch Management 


All Catalyst switches have the capability to be managed by an IP address. To accomplish this, an |P address needs to be assigned to the switch, 
along with a default gateway or default route for IP traffic to get forwarded to. The default management VLAN is VLAN 1. When you assign an IP 
address to the switch, it will be in VLAN 1 unless you specify another VLAN. 


Configuring Switch Management on Catalyst 4000/5500/6500 Switches 


The management interface on Catalyst 4000/5500/6500 series is called the SCO interface. This is a logical in-band interface, which means that it 
relies on another switch port to forward traffic for it. The 4000 series also has an out-of-band management interface called the ME1 interface. Use 
the following syntax to set the IP address for the Catalyst switch: 


set interface scO [vlan] [ip_addr [netmask [broadcast] ] ] 


A default route also needs to be set for IP to forward traffic to. This is usually a router with an interface on the same VLAN that the switch's IP 
address is in. A default route can be entered in one of two ways: by entering either a default gateway or the IP default route of 0.0.0.0. 


set ip route default IP_default_gateway 
Or 


set ip route 0.0.0.0 IP_default_gateway 


For full |P reachability, ensure that a router exists in the same subnet/VLAN as your management IP address. Use the router's Ethernet interface or 
subinterface as the default gateway IP address for the switch. 
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Example 2-1 demonstrates the configuration of an IP address and default gateway on the switch sw13. This default gateway is in VLAN 2. You need 
to proceed to Step 2 and configure VLAN 2 for this configuration to fully work. This is because VLAN 2 will not be in the database yet. 


Example 2-1 Configuring an IP Address and Default Route 


swl3 (enable) set int scO 2 172.16.2.13 255.255.255.0 
Interface sc0O vlan set, IP address and netmask set. 
swl3 (enable) set ip route default 172.16.2.10 

Route added. 


NOTE 


On the Catalyst 4000/5500/6500 series switches, the VTP domain and appropriate VLAN must be configured if the SCO interface is not 
on VLAN 1. 


Other commands that are useful in configuring general management on the Catalyst 4000/5500/6500 series switches are the following: 
e set prompt— Sets the prompt of the switch, just like the hostname command on routers. 
e set system contact— Sets a person's name or number to call for support. 
e set system location— Defines the physical location of the switch. 


e set ip routeip subnet ip_next_hope— Enables you to enter specific routes into the routing table. The next hop must be a reachable address 
through the scO or mel interface. 


e show ip route— Shows the known IP routes, or default routes, and how they are accessed. 


Example 2-2 demonstrates the entry of a static route, followed by the show ip route command. 


Example 2-2 Configuring Static Routes 
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swl3 (enable) set ip route 172.18.2.0 172.16.2.10 
Route added. 
swl3 (enable) show ip route 


Fragmentation Redirect Unreachable 

enabled enabled enabled 

Destination Gateway Flags Use Interface 
L726 185.2:.0 U722165.2 210 UG 0 scO 

LIZ 6165.20 172..16.2.13 U 279 scO 


swl3 (enable) 
Example 2-3 shows how the set system values are displayed with the show system command. 


Example 2-3 show system Command Output 


swl3 (enable) show system 
PS1-Status PS2-Status Fan-Status Temp-Alarm Sys-Status Uptime d,h:m:s Logout 


ok ok ok off ok OF 063359337 20 min 


PS1-Type PS2-Type Modem Baud Traffic Peak Peak-Time 


WwS-C4008 WwS-C4008 disable 9600 0% 6 Thu Jun 14 2001, 09:01:43 
System Name System Location System Contact 
switch13 CCIE Lab Solie 


swl3 (enable) 


NOTE 
VLAN 1: "Just Say No" 


VLAN 1 is the default VLAN for all Catalyst switches. MST on 802.1q uses this VLAN for its entire Spanning Tree domain. VLAN 1 has 
rules that limit how you can control traffic on it. Until recently, you could not even remove VLAN 1 from any trunk line. Any switch 
added to the network, by default, will be in VLAN 1. This leaves the network vulnerable to potential VLAN and data corruption on VLAN 


1. For these reasons, | personally don't run production traffic or management traffic on VLAN 1, which is essentially a "dead" VLAN. 


Configuring IP Permit Lists on Catalyst 4000/5500/6500 Switches 


When an IP address is configured on the switch, it can be accessed through Telnet and SNMP. There is no need for any additional configuration. 
Sometimes, you might want to limit Telnet or SNMP access to the switch. To limit this type of traffic, use the set ip permit command. Up to 10 line 
entries can be configured. Networks or single IP addresses can be filtered. For example, to allow only the network 172.16.2.0/24 to pass, the 
syntax would resemble the following: 


set ip permit 172.16.2.0 255.255.255.0 


To limit access to a single address, use a 255.255.255.255 mask or simply omit the mask. After the lines have been entered, enable the "access- 
list" with the set ip permit enable command. The switch will still allow |CMP echo replies and requests; however, it will block SNMP and Telnet 
traffic. By default, IP permit lists are disabled and need to be enabled to take effect. 


The syntax for IP permit is as follows: 


set ip permit [ip_address] [subnet_mask] 
set ip permit [enable | disable] 


IP permit lists can viewed by entering the show ip permit command, such as in Example 2-4. 


Example 2-4 show ip permit Command Output 


swl3 (enable) show ip permit 
IP permit list feature enabled. 


Permit List Mask 

172.16.2.0 255.255.255.0 

Denied IP Address Last Accessed Time Type 
1172.16.31 -—=—«:06/14/01,19:07:43 —Tednet 


swl3 (enable) 
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Configuring Switch Management on Catalyst 2900XL/3500G Families 


The management interface on Catalyst resembles a router with a special VLAN database added to it. The commands for assigning ports, trunks, 
and their management all are performed from the classic configuration mode, or conf t mode. VLAN information is configured from enable mode by 
using a special key-in, vlan database, from the enable mode. From this point on, we will refer to commands in the VLAN database as VLAN 
commands—that is, commands accessed by keying the vlan database from the enable mode prompt. Configuration commands entered from the 
more traditional router-like mode will be called configuration- mode commands. 


The 2900XL/3500G switch has a default virtual interface called VLAN 1. This is the default VLAN for the switch; if you want to configure the 
management IP address in VLAN 1, you would simply add it under this interface much like you would a router. To run management on a different 
VLAN, you will need to shut down the VLAN 1 interface and configure a new virtual interface for the VLAN that you want to run management on. 
Only one VLAN interface can be active at once; you must shut down VLAN 1 to activate VLAN 2. Example 2-5 demonstrates how to configure the 


management interface on a VLAN other than VLAN 1. 


Example 2-5 Configuring the Management Interface on Catalyst 2900XL/ 3500G Switches 


swll#econft t 

Enter configuration commands, one per line. End with CNTL/Z. 
swll (config) #interface vlan 1 

swl1l1(config-if) #shut 

swll1(config-if) #exit 

swll (config) #interface vlan 2 

swll(config-subif)#ip address 172.16.2.11 255.255.255.0 
swll(config-subif) #no shut 

swll1(config-subif) #*Z 

swll# 


In this particular example, the management interface will not work until VLAN 2 is defined on the switch. This is Step 2 of the four-part 
configuration process. 


To configure a default route, use the ip default-gateway ip address command, the same as it is on a router. Example 2-6 shows how to configure 
the default gateway. Here, the default gateway points at the router 172.16.2.10. 


Example 2-6 Configuring Default Routing on Catalyst 2900XL/ 3500G Switches 
swl5(config)#ip default-gateway 172.16.2.10 
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Controlling IP Access on Catalyst 2900XL/3500G Families 


Controlling IP access on the 2900XL/3500G switches is identical to controlling Telnet access on the router. Recall from Chapter 1 for configuring 
virtual Telnet access. 


Step 2: Configuring VTP and VLANs on Catalyst 4000/5500/6500 Switches 


This step contains three substeps, all performed with set commands. The three substeps are as follows: 


Step 1. Configure a VTP domain and mode. 
Step 2. Configure physical port properties and assign ports to VLANs. 


Step 3. Configure VLANs if the switch is operating as a VTP Server or in VTP transparent mode. 
Configuring VTP Domain and Mode on Catalyst 4000/5500/6500 Switches 


A VTP domain must be configured before any VLANs can be added to the VLAN database. To configure the VTP domain, use this syntax: 


set vtp [domain name] [mode {client | server | transparent}] [passwd passwd] 
[pruning {enable | disable}] [v2 {enable | disable}] 


The name field sets the VIP domain name and is a case-sensitive field. The default mode of VTP is server mode. If you want to change the mode, 
use either client, server, or transparent modes. Remember that any VLAN changes on the server are propagated to all client VLANs. For a server to 
send VTP updates to a client, it must have a higher revision number. If the client revision number is higher than the server's, it will not accept 
updates from the server. If you are having problems with VLANs propagating, be sure to check the revision number of VTP. To reset the VTP 
revision number, simply change the name of the VTP domain, and then change it back. This will reset the revision counter to 0. This will not work 
on 2900XL/3500G series switches; these switches must be restarted to clear a corrupt VTP domain. 


V2 updates can be enabled or disabled, depending on switch type. You need to use only version 2 updates during Token Ring switching, which is 
why Ethernet-only switches do not have V2 updates. All switches in the VTP domain must be V2-capable for this mode to work. 


VTP also uses and MD5 hash password protection for VTP updates. This can be simply enabled by adding the password command to the VTP 
domain. Example 2-7 demonstrates configuring a VIP domain ciscomd5 with the MD5 password of ccie. 


Example 2-7 Configuring a Password-Protected VTP Domain 
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swl3 (enable) set vtp domain ciscomd5 password ccie 
Generating MD5 secret for the password .... 

VTP domain ciscomd5 modified 

swl3 (enable) 


The VTP domain can be viewed with the command show vtp domain, as in Example 2-8. 


Example 2-8 Configuring a Password-Protected VTP Domain 


swl3 (enable) show vtp domain 
Domain Name Domain Index VTP Version Local Mode Password 


9 1023 0 disabled 
Last Updater V2 Mode Pruning PruneEligible on VLANs 
172. 16..2.13 disabled 2-1000 


swl3 (enable) 


The show vtp domain command lists the VTP domain name, revision index, and VTP modes and tells whether updates are password- protected. 
This command also shows the number of VLANs in the domain and tells which ones are prune-eligible. The Last Update row lists the IP address of 
the switch from which the last VTP update was received. In the previous example, the last update was received from 172.16.2.13. 


Configuring Physical Port Properties and Assigning Ports to VLANs on Catalyst 4000/5500/6500 Switches 


The next two steps might be combined into one step, depending on whether the switch is configured as a VTP server/transparent or client. 
Essentially, this step involves configuring VLANs and port characteristics. There is no need to configure VLANs if the switch is a VTP client. 


On the Catalyst switch, every port that is not a trunk will be assigned to the default VLAN, VLAN 1. If the port is assigned to any other VLAN, that 
VLAN must be created in the VLAN database. When trunk lines are configured, the VLANs created on the VTP server will be propagated to other VTP 
servers and clients. 


This step also calls for you to configure physical Ethernet properties, such as full- or half-duplex operation, port speed, and so on. The following 
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commands list some of the most common port configurations: 


set port disable[mod_num/ port_num]-— Disables a port, equivalent to the router shutdown command. 

set port enable[mod_num/ port_num]— Enables a port, equivalent to the router no shutdown command. 

set port duplex[mod_num/ port_num] [full] half]— Sets a port transmission type to full or half duplex. 

set port name[mod_num/port_num] port_name— Assigns a logical port name that will appear in the show port command. 


set port speed [mod_num/ port_num] [10] 100| auto]— Sets the port transmission speed to 10, 100, or autonegotiation. Gigabit 
Ethernet ports currently are fixed at 1000 Mbps; although this might change in the future. 


set port level [mod_num/ port_ num] [normal] high]— On the Catalyst 4000/ 5500/6500, if two ports access the switching bus 
simultaneously, a port with a "high" priority level will be serviced first. 


Port status can be viewed with the show port command. This version of the command lists all the ports on the switch, along with the VLAN ID of 
the port, connection status, duplex setting, speed, and interface type. Example 2-9 lists the output of the show port command. Notice how the 


logical port names help identify the port's function. Port 2/19 also is set for a high priority, with the set port level command. 


Example 2-9 show port Command Output 


swl13 
Port 


(enable) show port 


Name Status Vian Level Duplex Speed Type 

gigabit_trunk_swll connected trunk normal full 1000 1000BaseSxX 

gigabit_trunk_swl2 connected trunk normal full 1000 1000BaseSxX 
notconnect 1 normal auto auto 10/100BaseTX 
notconnect 1 normal auto auto 10/100BaseTX 
notconnect 1 normal auto auto 10/100BaseTX 
notconnect 1 normal auto auto 10/100BaseTX 
notconnect 1 normal auto auto 10/100BaseTX 
notconnect 1 normal auto auto 10/100BaseTX 
notconnect 1 normal auto auto 10/100BaseTX 
notconnect 1 normal auto auto 10/100BaseTX 
notconnect 1 normal auto auto 10/100BaseTX 
notconnect 1 normal auto auto 10/100BaseTX 
notconnect 1 normal auto auto 10/100BaseTX 
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2/14 connected 800 normal a-full a-100 10/100BaseTX 


2/15 notconnect 200 normal auto auto 10/100BaseTX 
2716 notconnect 200 normal auto auto 10/100BaseTX 
2717 notconnect 200 normal auto auto 10/100BaseTX 
2/18 notconnect 200 normal auto auto 10/100BaseTX 
2/19 internet_conn connected 100 high a-half a-10 10/100BaseTX 
2/20 100_trunk_sw15 connected trunk normal a-full a-100 10/100BaseTX 


Detailed information about a port can be viewed by appending the port number to the show port command. The detailed version of this command 
provides all the information that the show port command provides, plus detailed information on the physical properties of the port. These include 
security, port errors, and collisions. Example 2-10 lists the detailed version of the show port command. 


Example 2-10 Detailed Port Information 


swl3 (enable) show port 2/1 


Port Name Status Vian Level Duplex Speed Type 
eee es ee ee ae ae 
Port Security Secure-Src-Addr Last-Src-Addr Shutdown Trap IfIndex 
0 d@emiea °° t—C—i‘S No ee ee 
Port Send FlowControl Receive FlowControl RxPause TxPause Unsupported 

admin oper admin oper opcodes 
“2/1 desired off a 6 oo & @ 
Port Status Channel Channel Neighbor Neighbor 

mode status device port 

By eGehenbed ee ee  t~*S 
Port Align-Err FCS-Err Xmit-Err Rev-Err UnderSize 
Pye ee ee 
Port Single-Col Multi-Coll Late-Coll Excess-Col Carri-Sen Runts Giants 
7 Te Se 


as 


Last-—Time-Cleared 


sat Jun 16 2001,; 1ss29317 
swl3 (enable) 


Configuring VLANs on Catalyst 4000/5500/6500 Switches 


VLANs are created on the Catalyst 4000/5500/6500 series switches with the set vlan command. Ports can be added to the VLAN by simply 
appending the port number to the set vlan command: 


set vlan [1-1001] [mod/ports] 


The set vlan command automatically creates the VLAN, if previously undefined, and adds the port to the VLAN. Multiple ports can be added to a 
VLAN by adding them with a ",", or denoting a range with a "-". For example, to add ports 1/1 and 1/12 to VLAN 2, you would use the following 
syntax: 


set vlan 2 1/1,1/12 


To add ports 1/10 and ports 2/1, 2/2, and 2/3 to VLAN 3, you would use the following: 


Set vlan 3 1/10,2/1-2/3 
Example 2-11 demonstrates the creation of VLAN 33, and adding ports 2/5, 2/10, 2/11, 2/12, and 2/13 to that VLAN in a single statement. 


Example 2-11 VLAN Creation 


swl3 (enable) set vlan 33 2/5,2/10-2/13 
Vlan 33 configuration successful 

VLAN 33 modified. 

VLAN 1 modified. 

VLAN Mod/Ports 


33 2/1=2):2/ 57 2/10=13;, 2720 


swl3 (enable) 


178 


When you create a VLAN, it has certain default values, such as MTU, prune eligibility, and so on. Table 2-12 lists the default values of VLANs. Most 
of these values can be changed with the set vlan command, the syntax for which is as follows: 


set vlan 1-1001 [name {vlan_name}] [state {active | suspend}] [said {said_value}] 
[mtu mtu] [bridge {bridge_number}] [stp {ieee | ibm | auto}] 


The parameters for this command are described as follows: 
e name— Allows you to attach a 32-character name to the VLAN. 
e state— Allows you to suspend the VLAN. A suspended VLAN is propagated through VTP, but no user traffic will be carried on the VLAN. 
e Security Association |D (SAID)— Used to change the SAID value of the VLAN. The SAID value is used primarily in 802.10. 
e mtu, bridge, and stp— Allows you to change the default MTU value, bridge number, and STP type. Extreme caution should be used when 


changing the MTU, bridge number, and STP type. These values should be changed only when addressing a specific issue that requires it. 


Table 2-12. Default VLAN Settings 


| Feature | Default Value 
Native or default VLAN [VLAN 1 


Port VLAN assignments All ports assigned to VLAN 1; Token Ring ports assigned to VLAN 1003 
VTP mode Server 


VLAN state [Active 


Normal VLAN range VLAN 2 to VLAN 1001 
[*] VLAN 1006 to VLAN 1009 


VLAN reserved range 


[*] VLAN 1025 to VLAN 2094 
VLAN extended range 
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1500 bytes for Ethernet 


4472 bytes for Token Ring 


100,000 plus VLAN number 


VLAN2 = SAID 100002 


Prune eligibility VLANS 2 to 1000 are prune-eligible 
MAC address reduction eee 
[PVST 
Default FDDI VLAN [VLAN 1002 
WAN 1003. 


Default Token Ring TrCRF VLAN VLAN 1003 


Default FDDI Net VLAN [VLAN 1004 


Default Token Ring TrBRF VLAN VLAN 1005 with bridge number OF 
Spanning Tree version for TrBRF VLANs IBM 


SRB 


[*] The VLAN reserved range is used on the Cat 6500 series to map nonreserved VLANs. The VLAN extended range is available on the 
Catalyst 6500 series switch. This range is an extension of the normal VLAN range. The extended and reserved VLAN ranges are not 
be propagated by VTP at this time. Token Ring and FDDI VLANs are listed on Ethernet-only switches because of global VTP 
information. Likewise, Token Ring switches' VLAN database will list Ethernet VLANs. 


VLANs on the switch can be viewed in two ways. The show vlan command provides an overview of all the VLANs on the switch, their status, and 
what ports are assigned to them, along with the default VLAN values. Example 2-12 lists the output of the show vlan command. Notice how clear 
the VLAN name appears on the VLAN's assigned names. Assigning VLAN names will help the network self-document itself. 


Example 2-12 show vian Command Output 


swl3 (enable) show vlan 
VLAN Name Status IfIndex Mod/Ports, Vlans 
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active 4 2/3-4,2/6-9,2/21-34 


active 64 

active 65 

active 70 

active 71 

active 72 2/5,2/10-13 
active 66 ZFAD 
active 67 2/15-18 
active 68 2/14 
active 69 

active 5 

active 8 

active 6 

active 6 


Parent RingNo BrdgNo Stp BrdgMode Transl Trans2 


| 

| 

| 

| 

| 
©: © SO" SO OO: Or O'S: 7 O'S: © 
©) © SS OO '@ O'S. Oo. OS: @.o 


al default 

Zz management_VLAN 

3 Engineering_VLAN 

4 VLANO004 

5 LANOOO05 

33 LANO0033 

100 Internet_VLAN 

200 dummy_VLAN 

800 LANO800 

801 VLANO801 

1002 fddi-default 

1003 token-ring-default 
1004 fddinet-—default 

1004 fddinet-—default 

VLAN Type SAID MTU 
1 enet 100001 1500 
2 enet 100002 1500 
3 enet 100003 1500 
4 enet 100004 1500 
5 enet 100005 1500 
33 enet 100033 1500 
100 enet 100100 1500 
200 enet 100200 1500 
800 enet 100800 1500 
801 enet 100801 1500 
1002 fddi 101002 1500 
1003: -trert 101003 1500 
1004 fdnet 101004 1500 
1005 trbrf 101005 1500 
VLAN AREHops STEHops Backup 
1003 0 0 off 
swl3 (enable) 

VLAN AREHops STEHops Backup 
1003 0 0 off 
swl3 (enable) 
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By adding the VLAN number behind the show vlan command, it provides information on just that particular VLAN. Example 2-13 shows the output 
of the show vlan 2 command. 


Example 2-13 show vian2 Command Output 


swl3 (enable) show vlan 2 


VLAN Name Status IfIndex Mod/Ports, Vlans 

2 management_VLAN active 64 2/1-2,2/20 

VLAN Type SAID MTU Parent RingNo BrdgNo Stp BrdgMode Transl Trans2 
2 enet 100002 1500 = 7 - = = 0 0 


VLAN AREHops STEHops Backup CRF 


swl3 (enable) 


VLANs can be deleted from the database with the clear vlan vian_number command. VLANs can be deleted only if the switch is in a VTP server or 
it is in VTP transparent mode. When a VLAN is deleted on a VTP server, it removes the VLAN from the entire VTP domain. All switches in the VTP 
domain, VTP servers, and clients delete the VLAN from their database. For these reasons, caution should be used when clearing a VLAN. The switch 
will prompt you before final clearing of the VLAN, as shown in Example 2-14. Only the Cat 4000/5500/6500 will issue this warning when clearing a 
VLAN. VLANs on the Cat 2900XL and 3500G will be deleted when the changes are applied. 


Example 2-14 Deleting or Clearing a VLAN 


swl3 (enable) clear vlan 801 

This command will deactivate all ports on vlan 801 
in the entire management domain 

Do you want to continue(y/n) [n]?y 

Vian 801 deleted 

swl3 (enable) 


Step 2: Configuring VTP and VLANs on Catalyst 2900XL/3500G Switches 
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Configuring VTP and VLANs on the 2900XL/3500G series switches follows the same three substeps as the Catalyst 5500: 


Step 1. Configure a VTP domain and mode. 
Step 2. Configure physical port properties and assign ports to VLANs. 


Step 3. Configure VLANs if the switch is operating in VTP server mode. 
Configuring VTP Domain and Mode on Catalyst 2900XL/3500G Switches 


A VTP domain must be configured before any VLANs can be added in the VLAN database. The VLAN database is used to configure the VLAN 
properties of the switch. This we will refer to as the VLAN configuration mode. This mode is entered by the privileged command vian database. 
The router-like configuration mode is to configure the physical port properties and assign them to VLANs. To enter this mode, key in conf t. 


To configure the VTP domain use this syntax: 


Switch#vlan database 
(vlan) #vtp domain domain_name [password] 


If you add a password behind the domain name, VTP updates will use a MD5 hash. The default VTP mode will be server mode; to change the mode, 
use the following command from the VLAN configuration mode: 


(vlan) #vtp [server | client | transparent] 


For more information on the VTP mode, see the previous section, "VTP and Trunking Protocols." 


The VTP domain can be viewed using the show vtp status command. This command displays information about the VTP domain, such as 
configuration revision, domain name, operating mode, and so on. Example 2-15 lists the output of the show vtp status command. 


Example 2-15 Viewing the VTP Domain I nformation 


Switch#show vtp status 


VIP Version 2 

Configuration Revision 2 28 
Maximum VLANs supported locally : 254 
Number of existing VLANs + 13 


VTP Operating Mode : Server 183 


VTP Domain Name  Ciscomds 


VTP Pruning Mode : Disabled 
VIP V2 Mode : Disabled 
VIP Traps Generation : Disabled 
MD5 digest : OxD9 0x50 OxE2 Ox4F 0x09 OxDE 0x98 0x07 


Configuration last modified by 172.16.2.13 at 6-17-01 18:10:24 
swll# 


NOTE 


VLAN information is propagated only if the VTP revision number of the server is higher than the client's VTP revision number. If the 
VTP client's revision number is equal to or higher than the server's, it will not accept any VLAN information. To view the current VTP 
revision numbers, use the commands show vtp domain on Catalyst 4000/5500/6500 series switches and show vtp status on 


Catalyst 2900/3500 series switches. 


Configuring Physical Port Properties and Assigning Ports to VLANs on Catalyst 2900XL/3500G Switches 


The next step for VTP and VLAN configuration on Catalyst 2900XL/3500G switches is to configure any physical port properties, along with assigning 
the port to a VLAN. Physical port properties are changed from the configuration mode under the interface, much like you would do on a router. 
Example 2-16 demonstrates configuring an Ethernet port to 10-Mbps full duplex on a 2800 series switch. This example also assigns the logical 


name internet_port to the interface. 


Example 2-16 Configuring Physical Port Properties 


Switch#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
04:59:58: SSYS-5-CONFIG_I: Configured from console by console 
Switch (config) #interface fastEthernet 0/6 

Switch (config-if) #speed 10 

Switch (config—-if) #duplex full 

Switch (config-if) #description Internet_port 

Switch (config-if) #exit 


Some of the common physical properties of Ethernet that can be changed are as follows: 
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e duplex [full | half | auto]— Sets the port duplex mode. 
e speed [10 | 100 | auto]— Sets the port speed. 


e mtu [1500bytes-2018bytes]— Configures the MTU of the interface. Ensure that the MTU of the physical interface matches that of the 
VLAN, if you change this value. 


e description interface_description— Allows you to set a logical description for the interface. 
e shutdown | no shutdown-— Disables and enables the interface. 


The interface command switchport is used to assign VLANs to a port in one of three ways. The port can be set up to run as a trunk, or to run 


multiple or single VLANs. At this time, we will focus on assigning a port to a single VLAN. To accomplish this first, configure the port to be in access 
mode and then attach a VLAN to the port. The syntax used to accomplish this is as follows: 


(config-if) #switchport mode [access | multi | trunk] 
e access— Assigns the interface to a single VLAN. 


e multi— Used to assign the interface to multiple VLANs. The VTP domain must be transparent, and the interface must be attached to a 
switch or a router. 


e trunk— Used to configure the port as a trunk. We will discuss this option more in the next section. 
To assign the port to a VLAN, use the following command: 


(config-if) #switchport access vlan [1-1001 | dynamic] 


The VLAN standard range is 1 to 1001. The dynamic keyword is used in VLAN Membership Policy Server (VMPS) configurations. VMPS will not be 
covered in this text; for more information on VMPS, see the book Cisco LAN Switching, by Kennedy Clark and Kevin Hamilton. 


Example 2-17 demonstrates the configuration of FastEthernet 0/5 for VLAN 2. 


Example 2-17 Assigning VLAN 2 to Interface fast 0/5 
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Switch(config) #int fastEthernet 0/5 
Switch (config-if) #switchport mode access 
Switch (config-if) #switchport access vlan 2 


When the VTP mode is set to transparent, VLANs automatically are created with the switchport access vlan command. If the VTP mode is set as 
a client, you cannot configure VLANs on this switch. The VLANs must be configured on the server switch and propagated through VTP over a trunk 
to the client switch. 


Configuring VLANs on Catalyst 2900XL/3500G Switches 


The third step for VTP and VLAN configuration on Catalyst 2900XL/3500G switches involves configuring VLANs if the VTP mode is set as a server. 
VLANs are configured in the VLAN database simply by entering vlan [2-1001] options. Example 2-18 demonstrates the configuration of VLAN 175 
with the name backbone. Changes in VLANs must be activated with the apply command. All changes will be applied when the VLAN database is 
exited. If a mistake is made, VLAN changes can be canceled with the abort or reset commands. The abort command exits you from the VLAN 
database, while the reset command cancels the current changes and rereads the current database. 


Example 2-18 Configuration of VLAN 175 


Switch#vlan database 
Switch (vlan)#vlan 175 name backbone 
VLAN 175 added: 
Name: backbone 
Switch (vlan) #apply 
APPLY completed. 
Switch (vlan) # 


Other options might be configured on the VLAN from this mode. They include the following: 


Switch(vlan)# vlan vlan_num [name vlan_name] [state {active | suspend}] [said 
said_value] 


{mtu mtu] [bridge bridge_number] [stp type {ieee | ibm | auto} ] 
e name— Allows you to attach a 32-character name to the VLAN. 
e state— Allows you to suspend the VLAN. A suspended VLAN is propagated through VTP, but no user traffic will be carried on the VLAN. 


e said— Used to change the SAID value of the VLAN. The SAID value is used primarily in 802.10. 186 


e mtu, bridge, and STP— Allow you to change the default MTU value, bridge number, and STP type. 


For the default VLAN values, refer to Table 2-11 in the previous section. 


To find the status of VLANs on a 2900XL/3500G switch, use the same command used on the 4000/5500/6500 series switches. The show vlan 
vlan_number command displays all the VLANs on the switch, the state, and which ports are assigned to it. To display specific physical and logical 
information about a single VLAN, use the show vlan id vian_number]Example 2-19 lists the output of the show vlan command, followed by the 
more specific version of command. Notice again how the VLAN logical names help immediately identify the port purpose. 


Example 2-19 show vian Command Output 


swll#show vlan 

VLAN Name Status Ports 

al default active Fa0/2, Fa0/3, Fa0/4, Fa0/5, 
Fa0/6, Fa0/7, Fa0/8, Fa0/9, 
Fa0/11, Fa0/12, Fa0/13, Fa0/14, 
Fa0/15, Fa0/16, Fa0/17, Fa0/18, 
Fa0/19, Fa0/22, Fa0/23, Fa0/24, 
Fa0/25, Fa0/26, Fa0/27, Fa0/28, 
Fa0/29, Fa0/30, Fa0/31, Fa0/32, 
Fa0/33, Fa0/34, Fa0/35, Fa0/36, 
Fa0/37, Fa0/38, Fa0/39, Fa0/40, 
Fa0/41, Fa0/42, Fa0/43, Fa0/44, 
Fa0/45, Fa0/46, Fa0/47, Fa0/48, 


Gid0/2 
2 management_VLAN active 
3 Engineering_VLAN active Fa0/1 
4 VLANO004 active 
5 VLANO005 active 
oe) VLANO0033 active 
100 Internet_VLAN active 
200 dummy_VLAN active 
800 VLANO800 active 
1002 fddi-default active 
1003 token-ring-default active 
1004 fddinet-default active 
1005 trnet-default active 
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VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Transl Trans2 


i enet 100001 1500 = = = = = 0 0 
2 enet 100002 1500 = = = = = 0 0 
3 enet 100003 LSoo = = = - 7 0 0 
4 enet 100004 £500). = - = 7 - 0 0 
i) enet 100005 1500. = = = = = 0 0 
33 enet 100033 LOO. = = 7 - 7 0 0 
100 enet 100100 1300. = = 7 - = 0 0 
200 enet 100200 1500 = = = = = 0 0 
800 enet 100800 1500 = = = = = 0 0 
1002 fddi 101002 L500 = 0 = - = 0 0 
LOOS: er 101003 L500. = 0 - = srb 0 0 
1004 fdnet 101004 1500 = - 1 126 = 0 0 
1005 trnet 101005 1500 = = al ibm —- 0 0 
swll# 

swll#show vlan id 3 

VLAN Name Status Ports 

3 Engineering_VLAN active Fa0/1 

VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Transl Trans2 
3 enet 100003 1500. = = = = = 0 0 
swll# 


Step 3: Configuring VLAN trunks on Catalyst 4000/5500/6500 Switches 


Configuring trunks on the Catalyst is a two-step process: 


Step 1. Configure the port as a trunk. 


Step 2. Configure the trunk encapsulation to autonegotiate, or use ISL or 802.1q. 


Configuring the autonegotiation, or DTP, is more difficult than simply statically defining the trunk. This is mainly because of some of the differences 
in the default trunks for the various Catalysts switches. Most Catalysts default to ISL; however, the Catalyst 4000 without the Layer 3 module 
doesn't support ISL. Another example is that 802.1q autonegotiation is supported only in Software Release 4.2. It's these little things that can 
make DTP unreliable in large heterogeneous networks. 
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However, sometimes this feature is desirable. Table 2-12 lists all the modes and outcomes of DTP. By default, all ports are in a nontrunking status. 
You will have to configure each port as a trunk and put it into a mode. Recall from earlier that these are the five modes: 


e On-— Sets the port in a permanent trunking state. It also tries to negotiate the link to be a trunk. 
e Off— Disables the port, and thereby the trunk. 


e Desirable— Makes the port attempt to convert to a trunk link. The port becomes a trunk if the neighboring port is set to on, desirable, or 
auto modes. 


e Auto— Converts the port to a trunk if the neighboring port is set to on or desirable modes. 
e Nonegotiate— Puts the port into a trunk mode but prevents the port from sending DTP frames. 


When the port is configured as a trunk, the encapsulation must be set. There are three types of encapsulation, ISL, 802.1q/DOT1Q, and negotiate. 
The negotiate option will do just that; first it will try to negotiate an ISL trunk, followed by an 802.1q trunk. The syntax to accomplish these two 
steps is as follows: 


Switch (enable) set trunk mod_num/port_num [on | off | desirable | auto| nonegotiate] 
Switch (enable) set trunk mod_num/port_num [isl | dot1q] 


As mentioned previously, the most reliable and quickest way to configure a trunk without consulting Table 2-13 is to set the trunk to on and fix the 
encapsulation type to ISL or 802.1q/dotlq. Example 2-20 exhibits the configuration of an 802.1q trunk on port 2/6. 


Example 2-20 Configuring an 802.1q Trunk 


Switch (enable) set trunk 2/6 dotlq 
Port(s) 2/6 trunk type set to dotlq. 
Switch (enable) set trunk 2/6 on 


Port(s) 2/6 trunk mode set to on. 

Switch (enable) 2001 Jun 12 09:33:58 %DTP-5-TRUNKPORTON:Port 2/6 has become dotlq 
trunk 

Switch (enable) 2001 Jun 12 09:34:11 %PAGP-5-PORTTOSTP:Port 2/6 joined bridge port 
2/6 
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Table 2-13. Ethernet DTP Configuration Outcomes 


Trunk Mode 
Neighbor | and Trunk 
Port Encapsulation desirable| auto desirable desirable auto 
a or ee ISL ISL SoriG DOT1Q | DOT1Q |negotiate | negotiate 
DOT1Q 
off ISL or DOT1Q Local: Local: Local: Local: Local: 
Nontrunk |ISL trunk |Nontrunk Nontrunk Nontrunk Nontrunk Nontrunk Nontrunk 
Neighbor: |Neighbor: |Neighbor: Neighbor: Neighbor: Neighbor: |Neighbor: Neighbor: 
Nontrunk |Nontrunk |Nontrunk Nontrunk Nontrunk Nontrunk |Nontrunk Nontrunk 
on Local: Local: : ESL Local: Local: Local: Local: ISL 


Nontrunk jISL trunk ISL trunk Nontrunk Nontrunk 


NEI GHBOR: 
ISL 


Neighbor: 
ISL trunk 


Neighbor: 
ISL trunk 


Neighbor: 
ISL trunk 


Neighbor: 
ISL trunk 


Neighbor: 
Nontrunk 


ISL trunk 


» ISL 


Local: Local: ISL 


Nontrunk 


Local: 
Nontrunk 


Local: 
ISL trunk 


Local: 
ISL trunk 


Local: 
Nontrunk 


desirable |ISL 


NEI GHBOR: 
ISL 


Neighbor: 
Nontrunk 


Neighbor: 
ISL trunk 


Neighbor: 
ISL trunk 


Neighbor: 
Nontrunk 


Neighbor: 
Nontrunk 


ISL trunk 


ISL Local: 


Nontrunk 


Local: 
Nontrunk 


Local: 
Nontrunk 


Local: 
Nontrunk 


Local: 
ISL trunk 


Local: 
Nontrunk 


auto 


Neighbor: 
Nontrunk 


Neighbor: 
ISL trunk 


Neighbor: 
Nontrunk 


Neighbor: 
Nontrunk 


Neighbor: 
Nontrunk 


Neighbor: 
Nontrunk 


ISL trunk Nontrunk 
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Local: 
Nontrunk 


Neighbor: 


1Q trunk 


Local: 
Nontrunk 


Neighbor: 


Nontrunk 


Local: 
Nontrunk 


Neighbor: 


Nontrunk 


Negotiate Local: 
Nontrunk 


Neighbor: 


Nontrunk 


Negotiate Local: 
Nontrunk 


Neighbor: 


Nontrunk 


NOTE 


Local: 
ISL trunk 


Neighbor: 
1Q trunk 


Local: 
ISL trunk 


Neighbor: 
Nontrunk 


Local: 
ISL trunk 


Neighbor: 
Nontrunk 


Local: 
ISL trunk 


Neighbor: 
ISL trunk 


Local: ISL 


Neighbor: 
ISL trunk 


Local: 
Nontrunk 


Neighbor: 
1Q trunk 


Local: 
Nontrunk 


Neighbor: 
Nontrunk 


Local: 
Nontrunk 


Neighbor: 
Nontrunk 


2 ISL 


ISL trunk 


: ISLE 


Neighbor: 
ISL trunk 


Local: 
Nontrunk 


Neighbor: 


1Q trunk 


Local: 
Nontrunk 


Neighbor: 


Nontrunk 


Local: 
Nontrunk 


Neighbor: 


Nontrunk 


Local: 
ISL trunk 


Neighbor: 


ISL trunk 


Local: 
Nontrunk 


Neighbor: 


Nontrunk 


NEIGHBOR: 
1Q trunk 


Local: 1Q 
trunk 


Neighbor: 
1Q trunk 


Nontrunk 


Neighbor: 


Nontrunk 


Local: 
ISL trunk 


Neighbor: 


ISL trunk 


Local: 
Nontrunk 


Neighbor: 


Nontrunk 


Nontrunk 


Neighbor: 
Nontrunk 


Local: ISL 


Nontrunk 


Neighbor: 
Nontrunk 


Another autoconfiguration issue might arise with VTP and DISL. When DISL negotiates an ISL trunk, it includes the VTP name in the 
message. If the VTP domain names differ on the switches, the trunk will not become active. Again to circumvent this, simply COU 4 


the trunk to be on, and configure the encapsulation type. 


To view the status of a trunk, use the following commands: 


show trunk [detail] 
show trunk [mod_num/port_num] [detail] 
show vtp status 


Example 2-21 lists the output of show trunk command. If the trunk is not listed, some key fields to note are the following: 


Status 

Mode 

Encapsulation 

Vlans allowed and active in the management domain 
Peer-Port 


The status of the trunk should be trunking, and the mode should be on or should match a valid setting for DTP, as listed in Table 2-12. The 


encapsulation must match on both sides of the trunk. The "VLANs that are allowed and active in the management domain" states what VLANs the 
trunk is sending; if no VLANs are listed, the trunk is not configured properly. The native VLAN ID is the VLAN that 802.1q will use this VLAN for its 
single instance of Spanning Tree (MST). This VLAN must be the same throughout the VTP domain. 


Example 2-21 show trunk Command Output 


Switch (enable) show trunk detail 


Port Mode Encapsulation Status Native vlan 
2/1 on dotlgq trunking 1 
272, on dotlgq trunking 1 
Port Peer-Port Mode Encapsulation Status 
2/1 GigabitEt unknown unknown unknown 
2/2 GigabitEt unknown unknown unknown 
Port Vlans allowed on trunk 
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2/1 1=1005 


2/2 1-1005 
POErt Vlans allowed and active in management domain 

agi. 1-5; 33, 100, 200,800 

2f2 1-5, 33,100, 200,800 
Port Vlans in spanning tree forwarding state and not pruned 
271 1-5, 33,100,200, 800 

2/2 1=3 


Switch (enable) 


Sometimes, it might be hard to determine whether a trunk line is functioning. The trunk can report a status of trunking but not be in a fully 
exchanging VTP updates. The trunk status should be viewed on each side of the link, to ensure that it is functioning properly. Observing the Peer- 
Port status is another quick way to tell whether the trunk has recognized the other side of the link. If the Peer-Port status is unknown, it can mean 
that an encapsulation mismatch has occurred and that the trunk is not operating properly. 


As VTP synchronizes within the domain, the VLAN database from server to server and server to client will have the same VLANs listed in them. Only 
switches in the VTP transparent mode or trunks that have VLANs cleared will have different VLAN databases. Comparing the VLAN databases of the 
two switches connected by a trunk is another way to verify that the trunk is working. 


When the trunk becomes active, VTP advertisements will be sent and received. Three types of VTP advertisements occur on the trunk: 
e Subset advertisements— Subset advertisements are issued when you create, delete, or modify a VLAN. 


e Request advertisements— Request advertisements are issued from the switch whenever the Catalyst is reset or when a change in the 
local VTP domain occurs, such as a name change, or when the switch hears a VIP summary advertisement with a higher configuration 
revision number than its own. 


e Summary advertisements— Summary advertisements are issued every five minutes by the switch. The main purpose of the summary 
advertisement is for the switch to verify the VTP revision number, thereby ensuring that the VLAN databases are up-to-date. If it has a 
lower revision number, it issues a request for new VLAN information. 


You can observe VTP advertisements with the show vtp status command as demonstrated in Example 2-22. This should be used as another 
indicator that the trunk line is functioning properly. 
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Example 2-22 Observing VTP Advertisements with the show vtp status Command 


Switch (enable) show vtp status 
VIP statistics: 


summary advts received 66 
subset advts received 4 
request advts received 1 
summary advts transmitted 16 
subset advts transmitted 13 
request advts transmitted 0 
No of config revision errors 0 
No of config digest errors 0 


VIP pruning statistics: 


Trunk Join Transmitted Join Received Summary advts received from 
non-pruning-capable device 


274. 1047 1045 0 
2/2 1041 1046 0 
2/20 631 635 0 


Switch (enable) 


The show trunk command also lists the VLANs that are prune-eligible. Do not confuse prune-eligible VLANs with VLAN propagation. Prune-eligible 
means that unnecessary broadcast and user data, for a specific VLAN, will not be forwarded over trunk lines to switches that do not have an active 
port in that particular VLAN. By default, all VLAN information and Spanning Tree frames for each VLAN are advertised out all trunking interfaces. 
VLANs and STP can be removed from a trunk only by using the clear trunk command. We will discuss these functions more in the upcoming 
section "Step 4: Controlling STP and VLAN Propagation." 


NOTE 


Recall from the previous section that VTP information is communicated only from a VTP server to a VTP client if the VTP server revision 
number is greater than the client's. Extreme caution should be used whenever changing a VTP server or VTP client in a "synchronized" 
network. When the network is synchronized, all VTP revision numbers will match. When you make a change to VTP or the VLAN, the 
revision number will increment, so the switch that you are changing has a chance of becoming the device with the highest VTP revision 
number. This, in turn, could synchronize the whole network to this switch's VLAN database that you are modifying. 
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Step 3: Configuring VLAN Trunks on Catalyst 2900XL/3500G Switches 


Configuring trunks on this series of Catalyst is a two-step process just like on the Catalyst 5500 family: 


Step 1. Configure the port as a trunk. 


Step 2. Configure the trunk encapsulation to use ISL or 802.1q. 


By default, all ports are set to a nontrunking mode, so the first step is to configure the port as a trunk. The second step calls for you to set the 
encapsulation of the trunk. These steps are accomplished with the following commands from the interface configuration mode: 


(config-if) #switchport mode trunk 
(config-if) #switchport trunk encapsulation [isl | dotiq] 


Example 2-23 demonstrates the configuration of an ISL trunk. 


Example 2-23 Configuring an ISL Trunk 


Switch#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
Switch (config) #int fastEthernet 0/19 

Switch (config-if) #switchport mode trunk 

Switch (config-if) #switchport trunk encapsulation isl 

Switch (config—-if) #*Z 


To verify that the trunk is working, be sure to check the status of both sides of link, as mentioned previously. The output of the show interface 
interface_name switchport command presents a general status of the trunk. The information presented here is similar to the information for the 
show trunk command on the Catalyst 4000/5500/6500 switch. This command shows the status of the trunk and the encapsulation. VLAN 
information such as the default VLAN, the active VLANs on the links, and any prune-eligible VLANs also is listed. Example 2-24 lists the output of 
the show interface interface_name switchport command. 


Example 2-24 Status of a Trunk Line 


swl5#show int fastEthernet 0/19 switchport 
Name: Fa0/19 

Switchport: Enabled 

Administrative mode: trunk 
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Operational Mode: trunk 

Administrative Trunking Encapsulation: isl 
Operational Trunking Encapsulation: isl 
Negotiation of Trunking: Disabled 

Access Mode VLAN: 0 ( (Inactive) ) 

Trunking Native Mode VLAN: 1 (default) 
Trunking VLANs Enabled: ALL 

Trunking VLANs Active: 1-5,33,100,200, 800 
Pruning VLANs Enabled: 2-1001 

Priority for untagged frames: 0 

Override vlan tag priority: FALSE 

Voice VLAN: none 

Appliance trust: none 

swl5# 


Along with the trunk lines, the VTP domain counters should be examined using the show vtp counters command (see Example 2-25). This will 
help present a clearer picture on whether the trunk line is operational. 


Example 2-25 Determining the Status of a Trunk by Viewing VTP Counters 


swl5#show vtp counters 

VIP SstabsEics: 

Summary advertisements received 
Subset advertisements received 
Request advertisements received 
Summary advertisements transmitted 
Subset advertisements transmitted 
Request advertisements transmitted 
Number of config revision errors 
Number of config digest errors 
Number of V1 summary errors 


(=) 


oOo 


(Te & ap) a 9 © | ee a 
Ls) 


VIP pruning statistics: 


Trunk Join Transmitted Join Received Summary advts received from 
non-pruning-capable device 

Fa0/19 801 TdI2 0 

Fa0/20 1173 1164 0 

Fa0/21 
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In 802.1q networks, it is critical to ensure that the default VLAN is the same throughout the entire VTP domain. This is because 802.1q uses MST, 
and MST makes the entire VTP domain appear as a single-bridged domain to all third-party 802.1q switches. Cisco ensures compatibility with MST 
domains by implementing PVST+ along with MST. This is an extended version of Per VLAN Spanning Tree (PVST+) that provides seamless 
transparent integration for 802.1q networks. MST runs on the default VLAN, so it is important to have the same default VLAN throughout the entire 
internetwork. The default VLAN is 1. To change the default VLAN, use the following interface command on the trunk: 


(config-if) #switchport trunk native vlan vlan-id 
To change the native VLAN on a Catalyst 4000/5500/6500 series switches, create a VLAN on the same port that the 802.1 trunk is on. 
Step 4: Controlling STP and VLAN Propagation 


The final step for configuring Catalyst Ethernet switches is optional but can be extremely important in large networks. Cisco implements a couple of 
features that allow for switches to be plug-and-play in small networks, but these can have the negative effect of generating significant amounts of 
traffic in large networks. PVST, coupled with the default setting that every VLAN is communicated on every trunk port, can cause the edge switches 
to be overrun processing Spanning Tree requests and other broadcasts. 


For example, in the network in Figure 2-10, the crane switch has only a single VLAN, VLAN 2. But because this switch is in the same VTP domain as 


the other switches, it will participate in Spanning Tree for VLAN 3 and VLAN 4. There is no need for this switch to waste resources processing 
Spanning Tree requests for a VLAN that is not even on the switch. The larger and more redundant the network is, the worse the problem gets. For 
example, if you had 50 edge switches, there would be 50 separate Spanning Tree topologies on one trunk for one switch! And all of this happens 
before any user traffic can use the switch. 


Figure 2-10. VLAN Trunking and STP 
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It is a common misconception that VLAN pruning will solve STP issues. But VLAN pruning affects only user traffic—specifically broadcast, mybirast, 


and flooded unicast traffic. Basically, STP constructs the path that data can flow on, and pruning controls the "broadcast" data that flows on that 
path. 


Cisco offers two effective ways for dealing with excessive broadcasts and STP: 


e Clearing VLANs from trunks— Clearing VLANs off a trunk essentially removes those VLANs from the Spanning Tree topology for that 
trunk. The downstream switch no longer will receive BPDUs for the VLAN cleared. No user traffic for that VLAN will be capable of passing 
down this trunk. 


e VLAN pruning— VLAN pruning states that if VTP pruning is enabled, and if a downstream switch does not have an active port in that VLAN 
being pruned, the switch prevents the forwarding of flooded traffic to that prune-eligible downstream VLAN. VTP pruning is a method of 
traffic control that reduces unnecessary broadcast, multicast, and flooded unicast traffic. VTP pruning blocks flooded traffic to VLANs on 
trunk ports that are included in the pruning- eligible list. If the VLANs are configured as pruning-ineligible, traffic is flooded normally. 


In Figure 2-10, VLAN 2 is present on the crane, yin, and yang switches but not on the mantis switch. If VTP pruning is enabled for VLAN 2, the 
mantis switch will not receive broadcast, multicast, and flooded unicast traffic for VLAN 2. Likewise, the crane switch will not receive the flooded 
traffic from VLAN 3 and VLAN 4. 


The clearing trunks need to be performed on the "core" switches, or the VTP servers. All VLANs should be cleared, except the ones that exist on the 
downstream switch. Newer versions of Catalyst software allow for the clearing of VLAN 1. However, most switches still will not allow you to clear 
VLAN 1. To clear VLANs from trunks on the Catalyst 4000/5500/6500 family of switches, use the following command: 


Switch (enable) clear trunk [mod_num/port_num] vlans_2-1001 


Multiple VLANs can be cleared using a comma as a Separator and a hyphen for a range of inclusive VLANs. For example, to clear VLAN 3, VLAN 5, 
and VLANs 10 to 150, you would use the following command: 


Switch (enable) clear trunk 2/1 2,5 10-150 
To clear trunks from VLANs on the Catalyst 2900XL/3500G family of switches, use the following interface command: 
Switch (config-if) #switchport trunk allowed vlan [add | all | except | remove] vlans_2-1001 

e add— Adds the following VLANs to the trunk 


e all— Includes all VLANs on the trunk 
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e except— Includes all VLANs except the following 
e remove— Removes the following VLANs from the trunk 
For example, to clear VLAN 3 through VLAN 6, you would use the following command: 


Switch (config-if) #switchport trunk allowed vlan remove 3-6 


Figure 2-11 shows the same network as Figure 2-10, with updated interfaces names. In this example, on the yin switch, all VLANs except 1 and 2 
on the trunk to the crane switch will be cleared. Before clearing the trunk, examine Spanning Tree for the various VLANs on the yin switch. You will 
notice that Spanning Tree for all the VLANs is running on all trunks. Example 2-26 lists the output of the show spanning-tree command for VLAN 


3. This command is key to helping you understand and control Spanning Tree in switched networks. In the next section, we discuss this command 
in more detail. Notice that in Example 2-26, VLAN 3 is running on the trunk to the dragon router, the yang switch, and the crane switch. 


Figure 2-11. VLAN Trunking and STP 
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Example 2-26 Spanning Tree 1s Forwarding on All Trunks 


yin#tshow spanning-tree vlan 3 


Spanning tree 3 is executing the IEEE compatible Spanning Tree protocol 
Bridge Identifier has priority 32768, address 0004.275e.£5c2 
Configured hello time 2, max age 20, forward delay 15 
Current root has priority 32768, address 0004.275e.f0c2 
Root port is 67, Cost of root path is 4 
Topology change flag not set, detected flag not set, changes 1 
Times: hold 1, topology change 35, notification 2 

hello 2, max age 20, forward delay 15 
Timers: hello 0, topology change 0, notification 0 


Interface Fa0/10 (port 23) in Spanning tree 3 is FORWARDING 
Port path cost. 19, Port priority 128 
Designated root has priority 32768, address 0004.275e.f£0c2 
Designated bridge has priority 32768, address 0004.275e.f5c2 
Designated port is 23, path cost 4 
Timers: message age 0, forward delay 0, hold 0 
BPDU: sent 3766, received 0 


Interface Fa0/19 (port 33) in Spanning tree 3 is FORWARDING  ‘~ Trunk to the crane 
Porte path cost 19, Port. priority 128 
Designated root has priority 32768, address 0004.275e.f£0c2 
Designated bridge has priority 32768, address 0004.275e.£5c2 
Designated port is 33, path cost 4 


Timers: message age 0, forward delay 0, hold 0 
BPDU: sent 3768, received 1 


Interface Gi0/1 (port 67) in Spanning tree 3 is FORWARDING 
Port path cost 4, Port priority 128 
Designated root has priority 32768, address 0004.275e.f£0c2 
Designated bridge has priority 32768, address 0004.275e.f0c2 
Designated port is 67, path cost 0 
Timers: message age 2, forward delay 0, hold 0 
BPDU: sent 5, received 3773 

yin# 


In this particular example, the yin switch is a Catalyst 3500G series switch. Therefore, to clear the trunk, you should use the switchport 909 


command. Example 2-27 demonstrates the clearing of VLANs 3 to 1001 on the trunk between the yin and crane switches. The second portion of the 
example shows the Spanning Tree for VLAN 3. Notice that VLAN 3 is no longer forwarding out the trunk Fa0/19, the trunk line to the crane switch. 


Example 2-27 Clearing a Trunk of VLANs 


yin(config)#int fastEthernet 0/19 
yin (config—-if) #switchport trunk allowed vlan remove 3-1001 
yin (config—if) #*2Z 


yin#tshow spanning-tree vlan 3 


Spanning tree 3 is executing the IEEE compatible Spanning Tree protocol 
Bridge Identifier has priority 32768, address 0004.275e.£5c2 
Configured hello time 2, max age 20, forward delay 15 
Current root has priority 32768, address 0004.275e.f0c2 
Root port is 67, cost of root path is 4 
Topology change flag set, detected flag not set, changes 4 
Times: hold 1, topology change 35, notification 2 

hello 2, max age 20, forward delay 15 
Timers: hello 0, topology change 0, notification 0 


Interface Fa0/10 (port 23) in Spanning tree 3 is FORWARDING 
Pert path cost 19, Port priority 128 
Designated root has priority 32768, address 0004.275e.f£0c2 
Designated bridge has priority 32768, address 0004.275e.£5c2 
Designated port is 23, path cost 4 
Timers: message age 0, forward delay 0, hold 0 
BPDU: sent 4589, received 0 


Interface Gi0/1 (port 67) in Spanning tree 3 is FORWARDING 
Port: path ‘cost. 4, Port priority 128 
Designated root has priority 32768, address 0004.275e.f£0c2 
Designated bridge has priority 32768, address 0004.275e.f0c2 
Designated port is 67, path cost 0 
Timers: message age 3, forward delay 0, hold 0 
BPDU: sent 14, received 4593 

yin# 


The command show interface interface_name switchport allowed-vlan also shows what VLANs are carried on the trunk. The show trunk 
203 


command is the Catalyst 4000/5500/6500 equivalent of the command. Example 2-28 lists the output of the switchport command, showing that 
VLANs 3 to 1001 no longer appear on the trunk. VLANs 1002 to 1005 are not Ethernet VLANs and cannot be cleared on this trunk. 


Example 2-28 Showing the Allowed VLANs on a Trunk 


yin#show int fastEthernet 0/19 switchport allowed-vlan 
WI 2, 1002-1005" 
yin# 


Clearing trunk lines is one way to control STP, but for the switches that need redundancy, additional methods to control STP must be used. 
NOTE 
Monitoring Switch Ports with a Network Analyzers 


Switches do not forward all frames to every port in a VLAN. Recall that the switch is selective on what ports it forwards frames to, 
even when they are in the same VLAN. Because of this, you must enter a special command when monitoring a switch port with a 
network analyzer: 


set span {mod/src_ports} {dest_mod/dest_port_of_monitor} [rx | tx | both] 


Without this command, the network analyzer will not properly capture information on the VLAN you're monitoring. 


Configuring STP Root Placement 


Redundant switched networks do not perform any type of automatic load balancing. Because the STP forwarding/blocking decision is based in part 
on a static MAC addresses, all traffic tends to follow the same direction and the same path for all VLANs. This leads to some links being overutilized, 
while others remain idle. Figure 2-12 illustrates a network that has all converged on a single switch. The yang switch is the root of STP for VLANs 2, 


3, 4, and 5. 


Figure 2-12. STP Root 
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If you want to load-balance between the yin and yang switches, or if you were using HSRP on the dragon and tiger routers, you would want to 
control STP root placement. For example, if the dragon router was the HSRP primary for VLAN 2, you would want traffic to go through the yin 
switch instead of the yang switch. To control and distribute traffic in a switched network, the root for STP must be manually configured. 


There are multiple ways to configure the root of Spanning Tree for Catalyst switches. The methods that you use to set the root depend mostly on 
the environment that you trying to control. When setting the root bridge, you essentially are telling STP what ports to put into blocking and what 
ports to put into forwarding mode. Because STP is run on a per-VLAN basis (PVST), each VLAN can have a different root bridge. This enables you to 
send traffic over links that normally would not get used. In Figure 2-13, the yin switch is set to be the STP root for VLAN 4 and VLAN 5, while the 
yang switch is the STP root for VLAN 2 and VLAN 3. This causes the edge switches to balance their load more evenly over the trunks lines. VLANs 4 
and 5 will forward to yin, while VLANs 2, 3 will forward to yang. 


Figure 2-13. STP Root 
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Before we can further discuss how to set STP root, you must learn how to determine where the root bridge is located. The key command for this on 
the Catalyst 4000/5500/6500 is the show spantree vlan command. We prefer to use this command because Spanning Tree operates on a per- 
VLAN basis. Example 2-29 lists the output of the show spantree command. 


Example 2-29 Viewing Spanning Tree for VLAN 2 


crane (enable) show spantree 2 


VLAN 2 

Spanning tree enabled 

Spanning tree type ieee 

Designated Root 00-30-19-76-4d-01 

Designated Root Priority 88 

Designated Root Cost 0 

Designated Root Port 1/0 

Root Max Age 20 sec Hello Time 2 sec Forward Delay 15 sec 
Bridge ID MAC ADDR 00-30-19-76-4d-01 

Bridge ID Priority 88 

Bridge Max Age 20 sec Hello Time 2 sec Forward Delay 15 sec 
Port Vlan Port-State Cost Priority Fast-Start Group-Method 
2/4 2 forwarding 100 32 disabled 

2/19 2 forwarding 19 32 disabled 

2/20 2 forwarding 19 32 disabled 


crane (enable) 


Every bit of information provided by this command is useful. The fields are defined as follows (refer to the previous section of STP for more details): 
e Spanning Tree Type— The type of Spanning Tree Protocol in use—IBM, DEC, or IEEE. 
e Designated Root— The MAC address of the root bridge. 


e Designated Root Priority— The bridge priority that was received from the root bridge. The values of the bridge priority range from 0 to 
65,535, with 32,768 as the default. 208 


e Designated Root Cost— The cumulative cost to the root bridge. 

e Designated Root Port— The DR root port for that segment. 

e Root Max Age, Hello Time, Forward Delay— The three STP timers as sent by the root bridge. 
e Bridge 1D MAC ADDR— The MAC address that is being used for this VLAN by this local bridge. 
e Bridge 1D Priority— The priority of the local bridge. 

e Root Max Age, Hello Time, Forward Delay— The three STP timers on the local bridge. 


The final columns show each port that is participating in STP within the VLAN. They also list whether the port is forwarding or blocking, as well as 
the cost and service priority of the port. Do not confuse this priority with the Spanning Tree bridge priority. The values of the port priority ranges 
from 0 to 63 (high to low), with 32 as the default. 


The command to view Spanning Tree on a Catalyst 2900XL/3500G series switches is as follows: 


Switch#show spanning-tree vlan vlan 
The previous example (Example 2-26) demonstrated the output of this command. 


Another command that is useful in presenting a general operational picture of Spanning Tree is the show spantree summary command. This 
command provides an overview of the VLANs and tells how many ports and the state of the port. Example 2-30 lists the output for this command. 


Example 2-30 Viewing Spanning Tree for VLAN 2 


Switch (enable) show spantree summary 
Summary of connected spanning tree ports by vlan 


Uplinkfast disabled for bridge. 
Backbonefast disabled for bridge. 


Vlan Blocking Listening Learning Forwarding STP Active 
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1 a 0 0 al 2 

2 0 0 0 3 3 

3 0 0 0 2 Z 

4 0 0 0 2 2 
100 0 0 0 2 Z 
200 0 0 0 2 Z 
300 0 0 0 z Z 
Blocking Listening Learning Forwarding STP Active 

Total dl 0 0 14 15 


Switch (enable) 


To properly set the STP root, it helps to recall the four-step decision process that STP follows when determining root and which ports will forward 
and which ones will block. The four-step decision process is based on the following: 


1. Lowest root BID <Priority followed by MAC address> 
2. Lowest path cost to root bridge; the cumulative cost of the all paths to root 
3. Lowest sender BID 
4. Lowest port ID 
On the Catalyst 4000/5500/6500 series switches, four primary ways exist to control STP root selection: 


set spantree root 

set spantree priority 

set spantree portvlancost 
set spantree portvianpri 


The sections that follow examine the complete syntax and description for what each of these commands do. 
set spantree rootCommand 


The syntax for this command is as follows: 
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set spantree root [secondary] [vlan_list] [dia network_diameter] [hello hello_time] 


This command is a powerful macro that issues Spanning Tree commands to adjust the Spanning Tree timers until the local bridge/switch is elected 
root. It does this only once upon keying in the command. If other switches are added to the network, this command should be performed again. 
The Catalyst accomplishes this by examining the BDPUs of the existing root bridge. If the value of the priority is greater then 8192, the macro sets 
the local bridge priority to 8192. If the BPDU contains a priority less then 8192, the macro sets the local bridge priority to 1 less than that value. 
For example, the root bridge sends a configuration BDPU that is received by the new switch. The new switch, with the macro enabled, examines the 
priority of the BPDU and finds the value equal to 89. The macro then adjusts the local bridge priority to 88, thereby becoming elected as the new 
root bridge. The secondary option sets the bridge's local priority to 16,384. Recall that the default bridge priority is 32,768, so the value of 16,384 
is a reasonable choice for the backup bridge. The Diameter and Hello timers are used to adjust the hello and max age parameters of STP. Care 
should be used when adjusting any timers other then the bridge priority. This command exists only on the Catalyst 4000/5500/6500 series 
switches. 


set spantree priority Command 
The syntax for this command is as follows: 
set spantree priority [bridge-priority] [vlans] 


This command is a direct way to influence the bridge priority. Because the priority is the single most important factor in root selection, this 
command forces the election of root cleanly. The values of the bridge priority range from 0 to 65535. Valid values are 0, 4096, 8192, 12288, 
16384, 20480, 24576, 28672, 32768 (default), 36864, 40960, 45056, 49152, 53248, 57344, and 61440, with 0 indicating high priority and 61440 
indicating low priority. 


set spantree portvlancost Command 
The syntax for this command is as follows: 
set spantree portvlancost mod_num/port_num [eost 1-65535] [vlans] 


Use this command to influence the cost that Spanning Tree reports to downstream neighbors. This is the cost that STP uses when adding all the 
possible paths to root when determining which one is the least-cost path. Remember, a lower-cost path is more preferable. See Table 2-5 for a 


complete list of the default link cost values. 


set spantree portvianpri Command 
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The syntax for this command is as follows: 
set spantree portvlanpri mod_num/port_num [priority 0-63] [vlans] 


This command sets the port priority that the port will send to its downstream neighbors. Because the command can be performed on per-VLAN per 
port level, it can be useful. A primary use of this command is when switches want to load-share over multiple trunks among them. The values of 
the port priority range from 0 to 63, with 32 as the default, where 0 is a high priority and 63 is a low priority. 


Table 2-14 lists the commands along with where in the STP decision process the command is exerting influence. The higher up in the chart it is, the 
more powerful the command is in controlling root selection. 


Table 2-14. Ethernet DTP Configuration Outcomes 


Catalyst 4k/ 55k/ 65k set Catalyst 2900XL/ 3500G Global Configuration 
Command Command 


1-Lowest Root BID set spantree priority spanning-tree [vlan vlan_id] [priority 0-65535] 


set spantree root macro 


2-Lowest Path Cost to i spantree portviancost spanning-tree [vlan vian_id] [cost 1-65535] 
Root 


set spantree priority [spanning-tree [vlan vlan_id] [priority 0-65535] 
set spantree portvlianpri spanning-tree [vlan vian_id] [port-priority 0-255] 


Practical Example: Configuring a Routed and Switched Network 


Let's apply a couple of these concepts to a practical example. Figure 2-14 shows a fairly common network that consists of switches and routers. 
There are two active VLANs on the network, VLAN2 and VLAN4. VLAN2 is the management VLAN and has some user traffic in it. It has the IP 
subnet of 172.16.2.0/24. VLAN4 is strictly a user VLAN; it has the IP subnet of 172.16.4.0/24. The dragon router routes between the VLANs and 
serve as the default gateway for the switches. In this example, you will configure the following: 


Figure 2-14. Switched and Routed Network 
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e Basic |IP management, using 172.16.2.10 as the IP default gateway. 

e AnISL trunk between the router dragon and the yin switch. The dragon router will route between the VLANs using EIGRP as the routing 
protocol. 

e 802.1q trunks between the yin, crane, and mantis switches. 

e The appropriate VLANs, as indicated in Figure 2-14. 


This network has two kinds of switches in it, so we can demonstrate the commands used in both families of switches. Beginning with the yin switch, 
you need to configure an IP address and a default gateway, VLAN trunks, along with VLANs 2 and 4. Recall the four-step process to configure 
Ethernet switches: 

Step 1. Configure switch management. 

Step 2. Configure VTP and VLANs. 

Step 3. Configure VLAN trunks, if applicable. 

Step 4. (Optional) Control STP and VLAN propagation. 


To configure the management VLAN as VLAN 2, you need to define a virtual interface called VLAN 2 on the yin and mantis routers. Assign the 
management IP address to this interface, and activate it by shutting down the virtual interface vlan 1. Example 2-31 illustrates the first step of the 


configuration on the yin router. 


Example 2-31 Configuring Basic Management 


Switch#conf t 
Enter configuration commands, one per line. End with CNTL/Z. 


Been (cone at Neetaameayan *~ sets hostname 
“Disable interface VLAN 1 

yin (config-if) #shut 

yin (config—if) #exit 


— 


yin(config-subif) #ip address 172.16.2.11 255.255.255.0 
yin (config-subif) #exit 


yin (config) #ip default-gateway 172.16.2.10 9 *~ 
fa coca te aed | 214 


yin(config) # 
The management portion of the configuration on the mantis switch will resemble that of Example 2-31. 


Example 2-32 illustrates how to configure basic management on the crane switch, which is a Catalyst 4003. Because this series switch requires 


VLANs to be defined before the management VLAN can be moved off VLAN 1, you also will proceed to Step 2. Step 2 involves defining VLANs and 
the VTP domain. 


Example 2-32 Configuring Basic Management and the Default VLAN 


eee) eee — sets host name 
| set vp domain 
VTP domain cisco modified 
‘~ set VLAN 2 and name it 


Vlan 2 configuration successful 
crane (enable) 


‘“muct intertace 
Interface scO vlan set, IP address and netmask set. 
‘“befault route to dragon 
Route added. 
crane (enable) 


Step 2 requires you to configure the VTP domain—cisco, in this example—and define VLANs on the VTP servers. The mantis switch is the only VTP 
client, so you can begin with that switch. Example 2-33 demonstrates the configuration of VTP domain and shows how to change the VTP mode to 


client on the mantis switch. 


Example 2-33 Configuring VTP Domain and VTP Client 


mantis(vian)#vtp domain cisco == Set VIP domain name to cisco 


Changing VTP domain name from Null to cisco 
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Sep nee eros 
Setting device to VTP CLIENT mode. 
mantis (vlan) # 


After the VTP domain is created, switch ports can be assigned to VLANs. Example 2-34 illustrates the configuration of the mantis switch, assigning 
user ports to VLAN 2 and VLAN 4. 


Example 2-34 Assigning Ports to VLAN on the mantis Switch 


mantis#conft t 


Enter configuration commands, one per line. End with CNTL/Z. 

mantis (config) #interface fastEthernet 0/9 

ener ioe i Seat cope te ie sesceess epee eae ees 
SB ees 


mantis (config—-if) #exit 

mantis (config) #interface fastEthernet 0/5 
mantis (config-if) #switchport mode access 
mantis (config-if) #switchport access vlan 2 
mantis (config—if) #*Z 

mantis# 


Likewise, you must assign the ports 2/4 and 2/7 to VLAN 2 on the crane switch. Example 2-35 demonstrates this type on configuration. 


Example 2-35 Assigning Ports to VLAN on the crane Switch 


crane (enable) set vlan 2 2/4,2/7 
VLAN 2 modified. 
VLAN 1 modified. 
VLAN Mod/Ports 


2 2/4277 72/19=20 


crane (enable) 2001 Jun 26 21:15:08 %PAGP-5-PORTFROMSTP:Port 2/4 left bridge por 
t 2/4 


Example 2-36 shows the configuration of the VTP domain and VLANs on the crane switch, while the second half of the example coined ie 


same configuration on the yin switch. 


Example 2-36 Configuring VTP Domains and VLANs 


crane (enable) set vlan 4 


yin(vlan) #vtp domain cisco 
Changing VIP domain name from Null to cisco 
yin(vlan)#vlan 2 name management 
VLAN 2 added: 
Name: management 
yin (vlan) # 
yin(vlan)#vlan 4 
VLAN 4 added: 
Name: VLANOO004 
yin (vlan) # 


The third step calls for you to configure VLAN trunks between the switches. As we mentioned previously, configuring static trunks is a lot easier and 
quicker than trying to memorize the huge autonegotiation table. Example 2-37 demonstrates the configuration of an ISL and 802.1q trunk on the 


yin switch. 


Example 2-37 Configuring an ISL and 802.1q Trunk 


yin(config) #interface fast 0/10 
VED ONE tor fi Se een norte mca eras “set port to trunk 

*~ Set encapsulation to Ish 
yin (config-if) #exit 


yin(config) #interface fast 0/19 
yin (config—-if) #switchport mode trunk 


BR eee ee ae 
yin(config-if) #*Z 


Example 2-38 illustrates the configuration of the trunks on the crane switch. 


Example 2-38 Configuring 802.1q Trunks 
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Port(s) 2/19 trunk mode set to on. 


‘~ set port 2/19 to trunk 
_ 
SS Bas 


Port(s) 2/19 trunk type set to dotlq. 
2001 Jun 26 17:54:23 %DTP-5-TRUNKPORTON:Port 2/19 has 


become dotliq trunk 


crane (enable) set trunk 2/20 on 
Port(s) 2/20 trunk mode set to on. 


crane (enable) set trunk 2/20 dotlq 
Port(s) 2/20 trunk type set to dotlq. 


crane (enable) 


After the trunks are configured, you can check the status of the VTP domain on the VTP client switch, mantis. Example 2-39 illustrates that the VTP 
information is being communicated across the trunks. The show vlan command displays the new VLANs that the switch has learned. 


Example 2-39 Status of the VTP Domain on the mantis Switch 


mantis#show vtp status 
VTP Version 
Configuration Revision 
Maximum VLANs supported locally 
Number of existing VLANs 
VIP Operating Mode 

VTP Domain Name 

VTP Pruning Mode 

VIP V2 Mode 

VIP Traps Generation 

MD5 digest 


2 

7 

254 

7 

Client 

cisco 

Disabled 

Disabled 

Disabled 

0x51 O0x0C 0x00 Ox9A Ox0B 0x13 OxE3 OxBA 


Configuration last modified by 172.16.2.13 at 6-26-01 20:39:23 “~ VTP is receiving! 


mantis# 
mantis#show vlan 
VLAN Name 


il default 


Status POrts 


active Fa0/1, Fa0/2, Fa0/3, Fa0/4, 
Fa0/6, Fa0/7, Fa0/8, Fa0/9, 
Fa0/10, Fa0/11, Fa0/12, Fa0/13, 
Fa0/14, Fa0/15, Fa0/16, Fa0/17, 
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Fa0/18, Fa0/19, Fa0/21, Fa0/22, 
Fa0/23, Fa0/24 


2 management active Fa0/5 

4 VLANO004 active 

1002 fddi-default active 

1003 token-ring-default active 

1004 fddinet-default active 

1005 trnet-default active 

VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Transl Trans2 
il enet 100001 1500 = - = - = 0) 0 
2 enet 100002 1500 - - - = 7 0 0 
4 enet 100004 1500 <= = = - = 0 0 
1002 fddi 101002 TOO. = 0 7 7 = 0 0 
LOO3. jer 101003 1500 - 0 - - srb 0 0 
1004 fdnet 101004 500). <= = = ieee — 0 0 
1005 trnet 101005 T500° = = = ibm - 0 0 
mantis# 


Configuring a Trunk on a Router 


To route between VLANs, you need to have a router interface in each VLAN. Because solutions like this do not scale well because of the number of 
physical interfaces needed on large networks, you can configure an ISL or 802.1q trunk on the router. Cisco supports VLAN trunking on Ethernet 
router interfaces operating at least 100 Mbps. 


Configuring a trunk is much like configuring a Frame Relay subinterface. For VLAN trunks, you must create a logical Ethernet subinterface for every 
VLAN that you want to route between. You also must assign an encapsulation type to that subinterface. Finally, to actually "route," you need to 
enable a routing protocol. The subinterface will be treated just like a physical interface by the routing protocol. The syntax to accomplish this is as 
follows: 


Router (config) interface FastEthernet0. x 
Router (config-if)encapsulation [dot1Q [native native_vlan_id | isl] [vlan_id] 


Continuing from the previous model, Example 2-40 illustrates the configuration of a VLAN trunk on the dragon router. 
Example 2-40 Status of the VTP Domain on the mantis Router 
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dragon(config)#int fastEthernet 0/0.2 
_— 


dragon (config-subif) #ip address 172.16.2.10 255.255.255.0 
dragon (config-subif) #exit 

dragon(config)#int fastEthernet 0/0.4 

dragon (config-subif) #encapsulation isl 4 

dragon (config-subif) #ip address 172.16.4.10 255.255.255.0 
dragon (config-subif) #exit 


‘~ Configuring BIGRP 
dragon (config-router) #network 172.16.0.0 
dragon(config-router) #no auto-summary 


When this stage is complete, full |P connectivity will be established throughout the domain. All switches, routers, and hosts will be capable of 
pinging each other. 


Load Balancing Across Trunks 


In the previous model, there were no redundant trunks, so Spanning Tree was really not an issue. But if the model is modified slightly, we can 
insert some Spanning Tree issues into the network. 


Figure 2-15 presents a new network model with some minor changes. 


Figure 2-15. Load Sharing in a Switched Network 
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By adding another trunk line between the mantis and yin switches, a loop is created in the network. STP will now put some of the ports into 
blocking mode, to make the network loop-free. By also adding a two-port router, swan, with an interface in VLAN 2 and VLAN 4, we create a valid 
reason to want to load-share across this network. In a production environment, the swan router and the dragon router might be running HSRP 


between them. 


The results of how the network converges, or which paths go into forwarding and blocking, can be unpredictable. Most often, but not always, the 
traffic will tend to follow one path throughout the network. This leaves some links carrying all the traffic, while others are virtually unused. 


In Figure 2-15, we have configured another 802.1q between the yin and mantis switches, and added the router as denoted. If STP is observed for 


VLANs 1, 2, and 4 on the mantis switch, you can see that all the traffic is taking the new trunk, Fast 0/21, to root. The yin switch is root for all the 
VLANs in the VTP domain. Example 2-41 demonstrates the show spanning-tree vlan command on the mantis switch. 


Example 2-41 show spanning-tree Command Output on the mantis Switch 


mantis#show spanning-tree vlan 2 


Spanning tree 2 is executing the IEEE compatible Spanning Tree protocol 


Bridge Identifier has priority 32768, 
max age 20, 


Configured hello time 2, 


Root port. is: 35, 
Topology change flag not set, 


Times: hold 1, topology change 35, 
hello 2, max age 20, 
Timers: hello 0, topology change 0, 


Interface Fa0/5 (port 17) 
Port path cost. 100, 


Designated root has priority 32768, 
Designated bridge has priority 32768, 
path cost 19 

forward delay 0, 


Designated port is 17, 
Timers: message age 0, 
BPDU: sent 3066, received 0 


Port path cost. 19, 


Designated root has priority 32768, 
Designated bridge has priority 32768, 
path cost 19 


Designated port is 84, 


e6st Of root path is 19 
detected flag not set, 


notification 2 


forward delay 15 


notification 0 


address 00d0.976c.b781 
forward delay 15 


“Root MAC for VLAN 2 


changes 7 


in Spanning tree 2 is FORWARDING 
Port priority 128 


address 0004.275e.f5cl 


hold 0 


Port. priority 128 


address 00d0.976c.b781 


_— 
Saeed 


address 0004.275e.f5cl 


address 0030.1976.4d01 
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Timers: message age 3, forward delay 0, hold 0 
BPDU: sent 93, received 2972 


Interface Fa0/21 (port 35) in Spanning tree 2 is FORWARDING 
Port path cost. 19; Port priority 128 
Designated root has priority 32768, address 0004.275e.f5cl 
Designated bridge has priority 32768, address 0004.275e.f5cl 
Designated port is 35, path cost 0 
Timers: message age 3, forward delay 0, hold 0 
BPDU: sent 5, received 495 


mantis#show spanning-tree vlan 4 


Spanning tree 4 is executing the IEEE compatible Spanning Tree protocol 
Bridge Identifier has priority 32768, address 00d0.976c.b782 
Configured hello time 2, max age 20, forward delay 15 


Sle gO iiee earn o| 
Root port is.35, Cost, of root path is 19 


Topology change flag not set, detected flag not set, changes 5 
Times: hold 1, topology change 35, notification 2 

hello 2, max age 20, forward delay 15 
Timers: hello 0, topology change 0, notification 0 


Interface Fa0/9 (port 22) in Spanning tree 4 is FORWARDING 
Port path cost 100, Port priority 128 
Designated root has priority 32768, address 0004.275e.f5c2 
Designated bridge has priority 32768, address 00d0.976c.b782 
Designated port is 22, path cost 19 
Timers: message age 0, forward delay 0, hold 0 
BPDU: sent 1967, received 0 


Interface Fa0/20 (port 34) in Spanning tree 4 is BLOCKING 
POrt path cost. 19, Port. priority 128 
Designated root has priority 32768, address 0004.275e.f£5c2 
Designated bridge has priority 32768, address 0030.1976.4d03 
Designated port is 84, path cost 19 
Timers: message age 2, forward delay 0, hold 0 
BPDU: sent 1, received 2972 


Interface Fa0/21 (port 35) in Spanning tree 4 is FORWARDING 
Pork path cost. 19, Port priority 128 


Designated root has priority 32768, address 0004.275e.f£5c2 223 


Designated bridge has priority 32768, address 0004.275e.f5c2 
Designated port is 35, path cost 0 

Timers: message age 2, forward delay 0, hold 0 

BPDU: sent 5, received 498 


In this model, you want to load-balance the VLANs over the trunk lines from the mantis switch. All traffic from VLAN 2 will go to the swan router, 
while all traffic for VLAN 4 defaults to the dragon router. To accomplish this, you need to set the root for VLAN 2 to be the crane switch, while the 
root for VLAN 4 should be the yin switch. 


By using the set root macro command, you can set the root for VLAN 2 on the crane switch. Example 2-42 demonstrates the setting for the root 
for VLAN 2 on the crane switch. The command is preceded by the show spant 2 command, displaying the old and new root bridges for VLAN 2. 


Example 2-42 Setting Root for VLAN 2 


crane (enable) show spant 2 


VLAN 2 
Spanning tree enabled 
Spanning tree type ieee 
Designated Root Priority 32768 
Designated Root Cost 19) 
Designated Root Port 2/19 
Root Max Age 20 sec Hello Time 2 sec Forward Delay 15 sec 
‘~ our MAC for VLAN 2 
Bridge ID Priority 82.768 
Bridge Max Age 20 sec Hello Time 2. sec Forward Delay 15 sec 
Port Vlan Port-State Cost Priority Fast-Start Group-Method 
2/4 2 forwarding 100 32 disabled 
2/7 2 not-—connected 100 32 disabled 
2FL9 2 forwarding 19 32 disabled 
2/20 2 forwarding 19 32 disabled 


crane (enable) 
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VLAN 2 bridge priority set to 8192. 

VLAN 2 bridge max aging time set to 20. 

VLAN 2 bridge hello time set to 2. 

VLAN 2 bridge forward delay set to 15. 

Switch is now the root switch for active VLAN 2. 
crane (enable) 

crane (enable) show spant 2 


VLAN 2 
Spanning tree enabled 
Spanning tree type ieee 
“We are now the Root for VLAN 2 
Designated Root Priority 8192 
Designated Root Cost 0 
Designated Root Port 1/0 
Root Max Age 20 sec Hello Time 2 sec Forward Delay 15 sec 
Bridge ID MAC ADDR 00-30-19-76-4d-01 
Bridge ID Priority 8192 
Bridge Max Age 20 sec Hello Time 2 sec Forward Delay 15 sec 
Port Vlan Port-State Cost Priority Fast-Start Group-Method 
2/4 2 forwarding 100 32 disabled 
aga 2 not-—connected 100 32 disabled 
2/19 2 forwarding 19 32 disabled 
2/20 2 forwarding 19 32 disabled 


crane (enable) 


To verify the configuration, also check STP on the mantis switch, as listed in Example 2-43. The mantis switch now shows the root bridge for vlan 2 


as 0030.1976.4d01, which is the crane switch. Interface fast 0/20 is now forwarding for VLAN 2, and interface fast 0/21 has been put in blocking 
mode. VLAN 4 continues to have the yin switch as its root bridge. 


Example 2-43 STP Load Balancing 


mantis#show spanning-tree vlan 2 


Spanning tree 2 is executing the IEEE compatible Spanning Tree protocol 
Bridge Identifier has priority 32768, address 00d0.976c.b781 


Configured hello time 2, max age 20, forward delay 15 295 


Revere eos 
Root port is 34, cost of root path is 19 


Topology change flag not set, detected flag not set, changes 8 
Times: hold 1, topology change 35, notification 2 

hello 2, max age 20, forward delay 15 
Timers: hello 0, topology change 0, notification 0 


Interface Fa0/5 (port 17) in Spanning tree 2 is FORWARDING 
POLre path ‘cost. 100, Porte priority 128 
Designated root has priority 8192, address 0030.1976.4d01 
Designated bridge has priority 32768, address 00d0.976c.b781 
Designated port is 17, path cost 19 
Timers: message age 0, forward delay 0, hold 0 
BPDU: sent 4073, received 0 


Interface Fa0/20 (port 34) in Spanning tree 2 is FORWARDING 
Port path cost 19, Port. priority 128 
Designated root has priority 8192, address 0030.1976.4d01 
Designated bridge has priority 8192, address 0030.1976.4d01 
Designated port is 84, path cost 0 
Timers: message age 2, forward delay 0, hold 0 
BPDU: sent 95, received 3977 


Interface Fa0/21 (port 35) in Spanning tree 2 is BLOCKING 
POre. path cost 19, Port priority 128 
Designated root has priority 8192, address 0030.1976.4d01 
Designated bridge has priority 32768, address 0004.275e.f5cl 
Designated port is 35, path cost 19 
Timers: message age 3, forward delay 0, hold 0 
BPDU: sent 6, received 1502 

mantis# 


mantis#show spanning-tree vlan 4 


Spanning tree 4 is executing the IEEE compatible Spanning Tree protocol 
Bridge Identifier has priority 32768, address 00d0.976c.b782 
Configured hello time 2, max age 20, forward delay 15 
Current root has priority 32768, address 0004.275e.£5c2 
ROOt Pore is 35, Cost of root path is 19 
Topology change flag not set, detected flag not set, changes 5 
Times: hold 1, topology change 35, notification 2 


hello 2, max age 20, forward delay 15 226 


Timers: hello 0, topology change 0, notification 0 


Interface Fa0/9 (port 22) in Spanning tree 4 is FORWARDING 
Port path cost 100, Port priority 128 
Designated root has priority 32768, address 0004.275e.f5c2 
Designated bridge has priority 32768, address 00d0.976c.b782 
Designated port is 22, path cost 19 
Timers: message age 0, forward delay 0, hold 1 
BPDU: sent 3441, received 0 


Interface Fa0/20 (port 34) in Spanning tree 4 is BLOCKING 
Port path cost 19; Port priority 128 
Designated root has priority 32768, address 0004.275e.f5c2 
Designated bridge has priority 32768, address 0030.1976.4d03 
Designated port is 84, path cost 19 
Timers: message age 5, forward delay 0, hold 0 
BPDU: sent 1, received 4445 


Interface Fa0/21 (port 35) in Spanning tree 4 is FORWARDING 
POEE path cost 19, Port. praoraty 128 
Designated root has priority 32768, address 0004.275e.f£5c2 
Designated bridge has priority 32768, address 0004.275e.f£5c2 
Designated port is 35, path cost 0 
Timers: message age 3, forward delay 0, hold 0 
BPDU: sent 5, received 1972 

mantis# 


Figure 2-16 now shows how the network is handling and forwarding VLANs. 


Figure 2-16. Load Balancing over Trunks 
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To enforce consistent Spanning Tree selection throughout the network, you also should set the priority for VLAN 4 on the yin switch. This can be 
done using the priority command, as demonstrated in Example 2-44. 


Example 2-44 Setting Root on a Catalyst 2900XL/ 3500G Switch 


yin (config) #spanning-tree vlan 4 priority 100 
To verify the change, view STP for VLAN 4 on the mantis switch, as in Example 2-45. 


Example 2-45 Verifying the Priority of 100 for VLAN 4 


mantis#show spanning-tree vlan 4 


Spanning tree 4 is executing the IEEE compatible Spanning Tree protocol 
Bridge Identifier has priority 32768, address 00d0.976c.b782 
Configured hello time 2, max age 20, forward delay 15 
Current root has priority 100, address 0004.275e.f£5c2 
Root port is 35, cost. of root path as 19 
Topology change flag not set, detected flag not set, changes 5 
Times: hold 1, topology change 35, notification 2 

hello 2, max age 20, forward delay 15 
Timers: hello 0, topology change 0, notification 0 


The world of Ethernet switching is growing at a tremendous pace. There are many more interesting and useful technologies that we simply did not 
have the time to discuss. We highly recommend reading Kennedy Clark and Kevin Hamilton's book Cisco LAN Switching, which is loaded with 
information on LAN switching for extended reference. Some topics that you might want to pursue on your own that we did not cover in this book 
are listed here: 


e UplinkFast, PortFast, BackboneFast— These are ways to help the STP process deal with user traffic during initialization or failure while 
STP is converging. These technologies are simple to configure and can avoid lost throughput during STP convergence. 


e Fast EtherChannel/ Gigabit EtherChannel— EtherChannel provides a way for the router to aggregate up to four Fast Ethernet ports in a 
bundle. The technology also applies to Gigabit Ethernet. We like to think of EtherChannel as the PPP multilink of Ethernet. EtherChannel 
treats the bundle as one large physical link and can distribute traffic in different ways across the bundle. With full-duplex mode, 
EtherChannel bundles can reach speeds of 800 Mbps to 8,000 Mbps. EtherChannel can help avoid some STP issues because it offers 
resiliency between switches. When a link goes down, the bundle simply loses bandwidth and does not need to wait for STP to converge 
before sending user traffic. There are rules to EtherChannel and how ports can be bundled, and they are different for the various families of 
switches. There is also the drawback that EtherChannel can be used only to connect two switches—for example, bundles cannot be spt 


across switches. 


Port security— An advanced security function of all Cisco switches is port security. Port security allows you to limit the access on a port to 
a single MAC address. When another user plugs into the port with a different MAC address, the port can be shut down, or traps can be sent 
to a network-management station. This is a helpful feature in the field because it strictly controls physical access to the switch and 
unwanted moves or changes. 


Multicast (CGMP/ |1GMP)— CCIE Practical Studies, Volume | does not address any multicast issues. This does not mean that it is not 
important, however. Multicast traffic is playing an ever-increasing role in the modern network. CCIE Practical Studies, Volume II addresses 
multicast issues. 
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IEEE 802.5/Token Ring LANs 
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Token Ring: 30 Years Old and Still in Service 


If you have ever worked on IBM mainframes, AS400s, RS6000s, or any other SNA devices, 
chances are good that you have worked with Token Ring. And just as the mainframes were 
supposed to go away with the huge "client/server" push of the 1990s, eventually so would 
Token Ring networks. But the mainframes never become "extinct" like they were supposed 
to, and neither did Token Ring networks. The "big iron" mainframes are still present in many 
large networks, and most of them carry legacy Token Ring networks with them. 


Token Ring was conceived by IBM in the early 1970s, and it quickly became IBM's LAN of 
choice. Soon IBM front-end processors, such as the IBM 3745s, were shipping with Token 
Ring interfaces. At the time, Token Ring provided a fast LAN medium. Ethernet networks 
were operating at speeds of 10 Mbps or less on shared-media networks. It was highly 
debated how much "real" throughput you could get on an Ethernet segment with collisions 
and a large number of users. As you will see, Token Ring is somewhat deterministic and uses 
a token-passing technology that allowed it to achieve the speeds that it was advertising, 4 
Mbps and 16 Mbps. 
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Token Ring Technical Overview 


The IEEE officially adopted Token Ring as IEEE 802.5. The specifications are almost identical, with 
a few minor differences. IBM Token Ring calls for the stations to be attached by twisted-pair cable 
to a multistation access unit (MSAU) in a physical star topology. The IBM 8228 is a common 
example of a MSAU. The IEEE committee chose not to specify a medium or topology, allowing 
Token Ring networks to be more flexible. 


Token Ring/IEEE 802.5 operates strictly at Layer 2, like most LAN protocols. Like Ethernet, the 

IEEE committee divides the data link layer into two sublayers: 802.5 as the MAC layer and 802.2 
as the LLC layer. Functionally, [EEE 802.5 Token Ring parallels IEEE 802.3. The LLC layer—802.2, 
in this case—is a standardized interface between a hardware-specific MAC and a Layer 3 protocol. 


Token Ring Operation 


Token Ring networks have a physical topology of a star, but the network is treated as a logical 
ring. Figure 2-17 shows the logical and physical Token Ring topologies. 


Figure 2-17. Token Ring Topologies 
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Token Ring networks utilize a token-passing technology on the ring. Token- passing networks 
move a small frame, called a token, around the ring. Token Ring uses two types of frames, a 
token and an information/data frame. Token frames contain a start delimiter, an access control 
field, and an end delimiter. The data/command frames contain the same fields, plus a few more 
for user data, and also contain a source and destination address. When a station wants to 
transmit information, it must posses the token. Possession of token grants the right of the station 
to transmit data. If the station has no data to transmit, it simply passes the token along to the 
next station on the ring. 


When a station posses the token and wants to transmit, it changes a single bit in the access 
control field, the T bit. The station then appends its information to the frame and sends it on to 
the next station on the ring. The frame circulates the ring until it reaches the destination station, 
where the frame is then copied by the station and tagged as having been copied. The frame 
continues around the ring until it reaches the station that originated the frame. At this point, it is 
removed from the ring by that station. The concept of early token release allows a station that 
seizes a token to transmit a new token onto the ring after first sending its information frame. 


The following list describes some other important features that Token Ring employs to help data 
circulate throughout the ring: 


e Access control field— The access control field is an 8-bit field found in both types of 
Token Ring frames, the token and information/data frame. It contains the following 
information: 


p |p |p |t |m |R |R R 


- P— 3-bit priority field. Only stations with a priority equal to or higher than the 
priority of a token can claim that token. After the token is claimed and changed to 
an information frame, only stations with a priority higher than that of the 
transmitting station can reserve the token for the next pass around the network. 


- R— 3-bit reservation field used to reserve the token for the next pass around the 
ring. 


- T— Simply called the T bit. If the bit is set to 0, the frame is a token; if it is set to 
1, the frame is an information/data frame. 


- M— Monitor bit, used by the active monitor to remove endlessly circulating 
frames from the ring. 


e Active monitor— One station on the network serves as the active monitor. This station 
acts as a centralized source of timing information for other stations and performs a variety 
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of ring- maintenance functions. One such function is the removal of endlessly circulating 
frames from the ring. For example, when an originating station fails, it cannot remove its 
frame from the ring. This, in turn, will not allow any other stations to transmit on the ring. 
The active monitor can detect this type of failure through the use of the M bit mentioned 
previously and can properly remove the frame from the ring. 


e Reliable delivery— Token Ring uses a 2-bit frame status field to ensure reliable delivery 
of frames. These bits commonly are referred to as the A and C bits. An originating station 
generates a frame with the A and C bits set to 0. When the frame transverses the ring and 
arrives at the originating station, the bits are examined to verify delivery. Receiving 
stations modify the bits as documented in Table 2-15. 


Table 2-15. A and C Bit Modification by Receiving Station 


f Bit lia Bit Meaning 
0 0 [Destination not found. The receiving station did not modify the bits. 
pf Invalid, 


The frame was Pe but the station was incapable of copying 
data from the frame. 


i [2 IS tation found. The frame was accepted and copied. 


e Token Ring frame size— Token Ring frames have a significantly larger frame size than 
the 1518-byte Ethernet frame. Token Ring frames have a minimum size of 21 bytes at 4- 
Mbps and 16-Mbps ring operation. The largest frame size is 4511 bytes on 4-Mbps rings 
and 17,839 bytes on 16-Mbps rings. 


NOTE 
Canonical Versus Noncanonical Address Format 


Ethernet networks transmit data in what is called a canonical address format. This 
means is that if you have the bit stream 0110 1010, the most significant bit (MSB) is 
on the left and the least significant bit (LSB) is on the right. Ethernet networks 
transmit data in a canonical form, with the least significant bits get transmitted first. 
If an Ethernet network is sending the previous data steam, it would send0 10101 
1 0. Token Ring and FDDI networks transmit data in a noncanonical format. 
Noncanonical format transmits the most significant bit first. If a Token Ring network 
were transmitting the original bit stream mentioned, it would transmitO0 110101 
0. Source-route translation bridges and DLSw will perform address translation when 
needed. 
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Token Ring Switching 


Token Ring switching offers many of the same advantages as Ethernet switching. The major 
advantage is the speed that Token Ring switching provides. Much as Ethernet bandwidth is 
affected by the number of stations on a segment causing collisions, Token Ring bandwidth is 
affected by stations awaiting the token to transmit data. In a switched environment, ports on 
the same switch can belong to the same ring, but the stations on the switch ports will 
experience bandwidth as if they were the only stations on the ring. 


Token Ring switches also offer dedicated Token Ring (DTR). With traditional 4- or 16-Mbps 
Token Ring, Token Ring adapters are limited to half-duplex mode. DTR defines a method that 
allows the switch port to emulate a concentrator port and full-duplex data-passing mode 
called transmit immediate (TXI), which takes advantage of the fact that there is one end 
station on a port, and there is no real need to pass a token. Therefore, the adapter can 
transmit and receive simultaneously, where the ring can now use a theoretical bandwidth of 
32 Mbps. 


The Token Ring switch ports operate in the following modes: 


e Half-duplex concentrator port— The port is connected to a single station in half- 
duplex mode. The port behaves like an active MAU port for classical Token Ring. 


e Half-duplex station emulation— The port is connected to a port on an MAU. The 
port behaves like a station connected to a classical Token Ring segment that contains 
multiple stations. 


e Full-duplex concentrator port— The port is connected to a single station in full- 
duplex mode. 


e Full-duplex station emulation— The port is connected to a switch or a concentrator 
port in full-duplex mode. 


NOTE 


Duplex modes are a function of the hardware built into the network interface 
card. Software upgrades will not allow you to run full-duplex mode. For full- 
duplex mode to work, the station and switch port must be capable of full- duplex 
mode. 
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Token Ring Bridge Relay Function (TrBRF) and the Token Ring 
Concentrator Function (TrCRF) 


The Token Ring bridge relay function (TrBRF) functions like a multiport bridge. Its purpose is 
to bridge rings. The rings that it bridges are called Token Ring concentrator relay functions 
(TrCRF). (These probably would have been called virtual rings, but that name was already 
taken.) Multiple TrCRFs can attach to a single TrBRF, much like multiple rings can attach to a 
single bridge. TrCRFs can exchange data through source-route bridging (SRB) or source- 
route transparent bridging (SRT). If you are not familiar with these bridging technologies, 
you might want to read these sections of Chapter 13, "Configuring Bridging and Data Link 
Switching Plus." 


The TrBRF spans Catalyst switches, much like a Ethernet trunk. This allows TrCRFs on 
different Catalysts to belong to the same bridge number. Remember that the TrCRF is "the 
ring." A TrBRF must be created before a TrCRF is defined. Each TrBRF is identified by a bridge 
number and VLAN ID. When you create a TrCRF, you identify it with a ring number and 
another unique VLAN ID. The TrCRF must be assigned to a parent TrBRF. 


Figure 2-18 illustrates the TrBRF TrCRF relationship in the Catalyst 3920. The trbrf-default 
and the trcrf-default are the actual default TrBRF and TrCRF for all Catalyst switches. Think of 
them like an abstract VLAN 1 on Ethernet switches. Like Ethernet switches, Token Ring 
switches were designed to be "plug-and-play" on smaller networks. By default, all ports will 
be assigned to the trcrf-default, and the trcrf-default has TrBRF as its parent. 


Figure 2-18. Default TrBRF TrCRF Relationship 
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The concept of default TrBRFs and TrCRFs made LAN migrations from shared hub/MSAU 
environments easy. Out of the box, a Token Ring switch could be deployed without any 
configuration in place of a hub or MSAU. Like Ethernet switches ports that reside on the same 
default VLAN, Token Ring ports reside on the same default ring and bridge. Table 2-16 lists 
the default VLAN settings for Cisco switches. 


Table 2-16. Default VLAN Settings 
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Feature Default Value 


Native or Default VLAN VLAN 1 


Port VLAN assignments All ports assigned to VLAN1; Token 
Ring ports assigned to VLAN 1003 


VTP mode Transparent 
VLAN state Active 


Normal VLAN range VLAN 2 to VLAN 1001 


[*] VLAN 1006 to VLAN 1009 


VLAN reserved range 


[*] VLAN 1025 to VLAN 2094 
VLAN extended range 


MTU size 1500 bytes for Ethernet 


4472 bytes for Token Ring 


SAID value 


100,000 plus VLAN number 


VLAN2 = SAID 100002 


Prune eligibility VLANS 2-1000 are prune-eligible 


MAC address reduction Disabled 

Spanning Tree mode [PVST 

Default FDDI VLAN VLAN 1002 

Default Token Ring TrCRF VLAN VLAN 1003 

Default FDDI Net VLAN [VLAN 1004 

Default Token Ring TrBRF VLAN VLAN 1005 with bridge number OF 


Spanning Tree version for TrBRF IBM 
VLANs 
TrCRF bridge mode SRB 


[“] The VLAN reserved range is used on the Catalyst 6500 series and is used to 
map nonreserved VLANs. The VLAN extended range is available on the 
Catalyst 6500 series switch. This range is an extension of the normal VLAN 
range. The extended and reserved VLAN range is not propagated by VTP. 
Token Ring and FDDI VLANs are listed on Ethernet-only switches because of 
global VTP information. Likewise, Token Ring switches' VLAN database lists 
Ethernet VLANs. 


Figure 2-19 diagrams the logical layout of a Token Ring switch. Two TrBRFs were created on 
the switch. TrBRF brf100 will be bridge 10. This BRF is the parent to the TrCRF crf-ring10, 
which will be ring 10. All ports on the switch assigned to this CRF will be in ring 10. In this 
figure, ports 16 to 20 will all be on ring 10. The second TrBRF is used to link bridge 11 to ring 
11; ports 21-24 will be on ring 11. 
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Figure 2-19. Logical TrBRF TrCRF Relationship 
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When this switch is configured, you will have two bridging domains. Figure 2-20 shows 


another conceptual view of the same configuration, represented in a more traditional fashion. 


Figure 2-20. Conceptual View of TrBRFs and TrCRFs 


For the bridging domains to communicate, they need to be connected with another source- 
route bridge, usually in the form of a router. Figure 2-21 illustrates how the two domains can 


be linked with a router. If the network were transporting a bridged protocol such as SNA, 


the 


router could be configured for source-route bridging, and the two domains could be source- 


route bridged. If the network were transporting a routed protocol such as IP, the router 
would be configured to "route" traffic between the two domains. 


Figure 2-21. Linking Two Token Ring Bridging Domains 
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Configuring Token Ring Switching on the Catalyst 3920 


Many of the same concepts that are found in Ethernet switching apply directly to Token Ring 
switches. For example, VLANs, VTP domains, and management VLANs are all found on Token 
Ring switches. For that reason, we will not spend a lot of time redefining these terms and 
their application. Instead, we will focus primarily on switch configuration. 


The Catalyst 3920 does not have a standard command-line interface for configuration. 
Instead, the configuration is totally menu or panel-driven. The cursor keys allow you to select 
different panel options. To a large extent, this makes the configuration of the switches easy 
because there is no syntax to remember. 


Figure 2-22 shows the main panel of the Catalyst 3920 Token Ring switch. 


Figure 2-22. Initial Configuration Panel 
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The configuration panel is where the TrBRFs, TrCRFs, VLANs, management, and other 
software features of the switch are configured. The statistics panel is where the show 
commands for the switch reside. Port status, VTP status, and other important information 
about the operation of the switch can be viewed. The download/upload panel is where you 
can upgrade the Catalyst software. Finally, the reset panel is where you can clear NVRAM and 
reload the switch. Specifically, here is a quick guide to the important setting in each panel. 


The Switch Configuration Panel 


.-23 shows the switch configuration panel. 


Figure 2-23. Switch Configuration Panel 
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The panels available in the switch configuration panel are as follows: 


e Switch configuration— This panel allows you to display system information and 
switch hardware information, such as memory and software type. This panel also 
allows you to set basic switch management, such as system name, date, location, and 
contact information. You also can assign a MAC address to the switch here, and 
specify whether the switch will use canonical or noncanonical address formats. The 
default in Token Ring is noncanonical. Switch uplink information also can be accessed 
here. 


e Module information— This panel allows you to display information about the switch 
modules, their status, uptime, and hardware and firmware revision levels. 


e VLAN and VTP Configuration— This panel is where you will soend a majority of 
your time configuring the switch. At this panel, you can access and change the VTP 
domain, VLAN information, TrBRFs, and TrCRFs. Individual ports also are assigned to 
TrCRFs here. 


e IP configuration— This panel allows you to configure basic |P management of the 
switch. This includes the IP address and subnet mask, the default gateway. The IP 
address must be assigned to the management TrBRF to become active; that can be 
performed from the SNMP configuration panel. IP pings also can be sent from this 
panel when the management TrBRF and IP address are configured. 


e SNMP configuration— This panel allows you to set basic SNMP read/write, traps, 
and community strings. RMON is supported on the Catalyst 3920 and also can be 
activated here. The management VLAN or the management TrBRF must be defined 
here for SNMP and IP aspects of the switch work. By default, SNMP and IP are 
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configured to use the TrBRF-default entity. 


Spanning Tree— This panel allows you to configure STP in the bridged environment. 
All the same STP parameters and timers discussed earlier can be configured here for 
Token Ring networks. 


Token Ring port configuration— This panel displays and allows you to change 
physical and some logical port information. From this panel, you can set the duplex 
mode, early token release, MTU, and ring speed. You also can change the switching 
mode for the port from auto-cutthrough to one of the other three modes mentioned 
previously. This panel is where you also can tune explorer broadcasts. 


CDP configuration— This panel allows you to configure Cisco CDP information for 
the switch, as well as display its status. By default, CDP information is turned on for 
all switch ports. 


Switched port analyzer— This panel allows you to attach a network analyzer or 
similar device to the switch. This is always necessary when you are trying to monitor 
a switch port. This is because frames are not automatically forwarded to every port in 
the VLAN. 


Token Channel— This panel allows you to create a Token Channel. The first eight 
ports can be combined to form a Token Channel Interface. This technology is much 
like EtherChannel. 


Filters and port security— This panel allows you to enable MAC address and 
protocol filters. Port security is enabled from this panel as well. 


Password— This panel allows you configure a password for the switch. 


Console configuration— This panel allows you to configure and display current 
Telnet sessions. You also can configure the physical console port form this panel. The 
default session timeout is set to only 5 seconds; this can be changed to a maximum 
of 1440 seconds from this panel. 


The Statistics Panel 


This panel allows you to display various status information of the ports, VLANs, VTP, and 
other important information. The information panels that you can view include the following: 


Port status 

Port statistics 

Address tables 

Current Spanning Tree information 
VLAN statistics 

CDP neighbor display 

VTP statistics 

Diagnostic test results 

Message log information 

Display summary 


The Download/Upload Panel 
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From this panel, you can upgrade the switch's |OS. You can upgrade the switch through TFTP 
or the RS-232 interface. 


The Reset Panel 


From this panel, you can clear the NVRAM on the switch as well as reset it. The download/ 
upload panel allows you to perform the following: 


Reset switch with diagnostics 
Reset switch without diagnostics 
Reset port address table 

Clear nonvolatile RAM 


Configuring VLANs on the Catalyst 3920 


The logical steps for configuring VLANs for Token Ring resemble the same steps that you use 
for configuring Ethernet VLANs. With Token Ring, however, you must define rings and 
bridges, which require a few extra steps. The steps for configuring VLANs on the Catalyst 
3920 switch are as follows: 


Step 1. Plan TrBRFs, TrCRFs, ring numbers, bridge numbers, and VLANs. 
Step 2. Configure VTP. 
Step 3. Configure TrBRF VLAN(s) and assign a bridge number to each TrBRF. 


Step 4. Configure TrCRFs VLANs and assign a parent TrBRF and an optional ring 
number. 


Step 5. Assign ports to TrCRFs. 


Step 6. Configure switch management. 
Configuring Token Ring switching involves configuring a TrBRF VLAN and TrCRF VLAN. This 
relationship can get rather confusing because there are two VLANs, rings, bridges, and so on. 


For this reason, you should really take the extra time and lay out a small diagram showing 
the logical relationships among all these entities. 


Figure 2-24 shows two perspectives of the same Token Ring network. The dragon_ switch is 
Cisco Catalyst 3920; it connects two routers and a user workstation. Let's walk through the 
six-step process to configure this switched Token Ring network. 


Figure 2-24. Token Ring Switched Network Model 
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Step 1: Planning TrBRFs, TrCRFs, Ring Numbers, Bridge Numbers, and VLANs 


In Step 1, you plan for VLANs, TrBRFs, and TrCRFs. Figure 2-25 diagrams the network from 
the dragon_ switch perspective. You will define two TrBRFs and the associated VLAN and 
bridge number for them. You also need to define two TrCRFs, the VLAN for them, and an 
appropriate ring number. The TrCRF is linked to the TrBRF by declaring it a parent. The TrCRF 


is not linked to the TrBRF by a common VLAN. The VLANs and bridge numbers do not need to 
match. 


Figure 2-25. Defining TrBRFs and TrCRFs 
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To help self-document the network, try to form some logical naming convention. In this 
example, TrBRF is called brf5; it is on VLAN 50 and bridge 5. It is the parent of crf-ring5, 
which is VLAN 5, which contains ring 5. The other TrBRF will be called brf6 and has VLAN 60 
and bridge 6. This TrBRF will be the parent of TrCRF crf-ring6, and crf-ring6 contains VLAN 6 
and, you guessed it, ring 6. 


Step 2: Configuring VTP 


In Step 2, you can begin to configure the switch. From the initial configuration panel, select 
the VLAN and VTP configuration panel. From this panel, you can enter the VTP administrative 
configuration panel, shown in Figure 2-26. In the VTP administrative configuration panel, you 
can set the VTP domain name, VTP mode, and a password, if you are configuring one. 


Figure 2-26. VLAN and VTP Configuration Panel 
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Figure 2-27 displays the VTP administrative configuration panel with the configuration of 


cisco as the VTP domain name. 


Figure 2-27. VTP Administrative Configuration Panel 
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Step 3: Configuring TrBRF VLAN(s) and Assigning a Bridge Number to Each TrBRF 


Step 3 tells you to configure TrBRFs and their associated VLANs and assign a bridge number 
to the TrBRF. As mentioned previously, you will need to configure two TrBRFs. TrBRFs are 
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configured from selecting the VTP VLAN configuration panel under the same VLAN and VTP 
configuration panel. From this panel, select Add to create a new TrBRF. Notice that it says to 
enter a VLAN; this is the VLAN within the TrBRF. Figures 2-28 and 2-29 display the creation 
of the TrBRF brf5 VLAN 50. 


Figure 2-28. VTP VLAN Configuration Panel 
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Figure 2-29. VLAN Parameters Configuration Panel 
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When you create a new VLAN, the switch prompts you to make it either a TrBRF or a TrCRF 
VLAN. By selecting the TrBRF option when you create the VLAN, you are taken to the VLAN 
Configuration Parameters menu. From this menu, you can enter the TrBRF name and change 
the VLAN ID, state, and MTU. This menu also allows you to select the bridge number for the 
VLAN. The bridge number is displayed and entered in hexadecimal format. When performing 
source-route bridging in the future, be careful not to get bridge |Ds mixed up by entering 
some in hex and some in decimal. Figure 2-29 displays the VLAN parameters configuration 
panel. 


Step 4: Configuring TrCRFs VLANs and Assigning a Parent TrBRF and an Optional 
Ring Number 


After both TrBRF VLANs have been defined, Step 4 calls for you to define the TrCRFs and link 
them to a parent TrBRFs. To create a TrCRF, create another unique VLAN in the same 
manner as mentioned previously. This VLAN is not used to link the TrCRF to the TrBRF, and it 
needs to have a unique VLAN ID. When prompted for the VLAN type, select TrCRF. Example 
’-30 displays the creation of TrCRF VLAN 5. 


The VTP VLAN Configuration menu for TrCRFs can be found in Figure 2-31. From this panel, 
you can assign the VLAN a name and parent VLAN. We have named this VLAN crf-ring5 for 
some extra documentation. Most important is the parent VLAN; here, you want to assign a 
parent VLAN of brf5. The ring number is set at a default of auto, which means that the switch 
will be capable of determining from the RIF what the actual ring number is. In this example, 
you want to statically configure the ring to be ring 5. The ring number is displayed and 
entered in hexadecimal. 


Figure 2-30. VTP VLAN Configuration Panel 
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Figure 2-31. VLAN Parameter Configuration Panel 
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Figure 2-32 displays the VTP VLAN configuration panel listing the new VLANs created. 


Figure 2-32. VTP VLAN Configuration Panel 
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Step 5: Assigning Ports to TrCRFs 


Step 5 involves configuring the actual Token Ring switch ports and assigning them to a TrCRF 
VLAN. From the VLAN and VTP configuration panel, the third option, Local VLAN Port 
Configuration, allows you to change the default TrCRF that all the ports are assigned to. As 
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mentioned previously, all ports are assigned to the TrCRF called TrCRF-default. When you 
select the Change option, the switch prompts you for the port that you want to change. After 
the port has been entered, the switch dene you with the current TrCRFs that it is aware of 
and allows you to change these. Figure 2-33 shows the Local VLAN port configuration panel 
after ports 1 to 3 have been modified. 


Figure 2-33. Local VLAN Port Configuration 
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At this point in the configuration, the switch is fully operational. To configure the routers in 
ins dene ih simply need to configure the Token Ring interface and basic routing. 

xample 2-46 illustrates a simple Token Ring configuration, such as the one on the crane 
router. 


Example 2-46 Basic Token Ring Configuration on the crane Router 


crane (config) #int tokenRing 0 

crane (config—if) #ring-speed 16 

crane (config-if)#ip address 172.16.128.3 255.255.255.0 
crane (config-if) #no shut 


Step 6: Configuring Switch Management 


The final step in the configuration is to set up IP access and management. Switch 
management, such as contact name and information, and canonical address formats can 
changed from the switch configuration panel. Figure 2-34 displays this panel. 


Figure 2-34. Switch Configuration 
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IP configuration, such as an IP address for the switch, and a default gateway are entered 
from the IP configuration panel. When this panel is selected, the switch prompts you for a 
TrBRF VLAN to put the address on. It lists all the TrBRFs that it knows about. After a TrBRF is 
selected, the IP configuration panel displays. In this panel, you can enter an IP address, 
subnet mask, and default gateway. You also can configure the switch to use BootP from this 
panel. Figure 2-35 shows the IP configuration panel. 


Figure 2-35. 1P Configuration Panel 
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ICMP pings also can be issued from this panel; however, the switch can have only one 
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management address active at a time. Until the management VLAN is changed, the switch 
uses the VLAN trbrf-default. Much like the Catalyst 2900 and 3500 can have multiple virtual 
interfaces with IP addresses defined, only one can be active at any given time. To change the 
active VLAN for management from trbrf-default to another TrBRF VLAN, select the SNMP 
panel from the configuration panel. The SNMP panel also allows you change the default VLAN, 
as well as enable RMON and SNMP traps and define community strings. Figure 2-36 displays 
the SNMP configuration panel, showing the new TrBRF-default to be brf5. 


Figure 2-36. SNMP Configuration Panel 
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Switch operation can be verified from the main configuration menu. Under the main 
configuration menu, the Statistics option offers a vast array of statistics to view. The most 
useful statistics are port statistics and VLAN statistics. The best way to become familiar with 
the commands that are put into menus such as this is not to spend time reading about them 
in a book, but to simply spend time selecting and viewing the different options on the switch. 
shows the statistics panel, listing the tip of the iceberg of available options. 


jure 2-38 shows the Port Configuration menu, which is another useful way to view the port 


Figure 2-37. Statistics Panel 
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Figure 2-38. Port Configuration 
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More Practice: Ethernet/Token Ring Labs 


Throughout the rest of this book, you will get ample opportunities to configure Ethernet and 
Token Ring VLANs. All the labs in the chapters on routing protocols and subsequent chapters 
involve configuring LANs in one form or another. Make the most of these sections if you have 
the equipment available. For example, instead of using hubs to practice modeling your 
networks, create VLANs and VLAN trunks. 


The following labs involve most of the concepts we've discussed. Instead of having many 
small labs, one in which you configure a VLAN, one in which you configure a VLAN trunk, and 
so on, we decided to make the labs in this book rather complex so that they not only 
challenge you but also present you with "practical" scenarios that you might face in the field. 
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Lab 7: Ethernet Switching, VLAN Trunking, and Spanning Tree Root 
Placement—Part | 


Practical Scenario 


Small Ethernet networks, for the most part, are plug-and-play. Even when Ethernet switches are 
deployed in small networks, they are user-friendly and not much configuration is needed. It is 
when redundancy is added to the network that things get more complicated. This lab gives you 
practice in configuring a redundant Ethernet switched networks and the challenges associated 
with them. 


Lab Exercise 


Game LANs, Inc. is a company that provides high-speed backbones for entertainment centers 
around the country. Game LAN uses Cisco 100-Mbps and Gigabit Ethernet switches to provide the 
switch fabric for the LANs that the company installs. A part of all Game LAN networks is the 
redundancy that is built into each design. 


Your task is to configure a Game LAN network by using the following parameters as design 
guidelines: 


e Configure an Ethernet switched network as depicted in Figure 2-39. 


Figure 2-39. Game LAN Ethernet Network 
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Use the VTP domain name, funtime, for all the switches in the network. 

Create three VLANs on this network, and do not use VLAN1. Create one VLAN for 

management, which is IP subnet 172.16.128.0/24. Mark this VLAN so that it stands out as 

the management VLAN when being viewed by other switches. Two other VLANs are 

needed, one for the glaccess_ 2 router, 172.16.16.0/24, and one for the glaccess_1 router 

on subnet 172.16.17.0/24. 

Configure the gameserver_1 and the gameserver_2 routers to route among all the VLANs 

on the network. All VLANs and IP address should be capable of reaching each other. Use 

EIGRP as the routing protocol, and use 2001 as the Autonomous System ID. 

Tune STP so that the root for all VLANs corresponds to the HSRP configuration. The root 

for VLANs 128 and 17 should be gl_switch1, and the root for VLAN 16 should be 

gl_switch2. 

Configure the gl_ switch so that only devices on the subnet 172.16.17.0/24 can Telnet to 

the switch. 

(Optional) Port 2/24 contains a secure workstation. It has a MAC address of 

0000.863c.3b41. Configure this port so that only this workstation will work on it, and shut 
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it down if another workstation is plugged into it. 


Lab Objectives 


Configure an Ethernet switched network as depicted in Figure 2-39. 


Use a single VTP domain throughout the network. Configure gl_switch1 and gl_switch2 as 
VTP servers, and configure gl_switch3 as a VTP client. Configure the VLAN trunks and 
trunk type as denoted in the Figure 2-39. Be sure to configure both types of trunks, 
802.1q and ISL. 

Ensure full IP connectivity to all |P interfaces—that is, be sure that you can ping all LAN 
interfaces. 

Create three VLANs on this network, and do not use VLAN1. Create one VLAN for 
management, which is IP subnet 172.16.128.0/24; one for the glaccess_ 2 router, 
172.16.16.0/24; and one for the glaccess_1 router on subnet 172.16.17.0. 

Configure the gameserver_1 and the gameserver_2 routers to route among all the VLANs 
on the network. For this lab, you will user EIGRP as the routing protocol. Configure HSRP 
between these routers. Use the first |P addresses on each subnet as the HSRP shared 
address. For example, subnet 172.16.128.0/24, the management subnet, should use 
172.16.128.1 as the HSRP shared address. Configure HSRP so that the gameserver_2 is 
the primary for the subnet 172.16.16.0/24 and the gameserver_1 router is the HSRP 
primary for subnets 172.16.128.0/24 and 172.16.17.0/24. All VLANs and IP address 
should be capable of reaching each other. 

Configure STP so that the root for VLANs 128 and VLAN 17 is gl_ switch1 and the root for 
VLAN 16 is gl_switch2. 

Configure the gl_ switch so that only devices on the 172.16.16.0/24 can Telnet to the 
switch. This can be the only device that can Telnet and manage the switch. 

(Optional) Port 2/24 contains a secure workstation. It has a MAC address of 
0000.863c.3b41. Configure this port so that only this workstation will work on it, and shut 
it down if another workstation is plugged into it. 


Equipment Needed 


Four Cisco routers with Ethernet interfaces. Two routers must have 100-Mbps interfaces. 
Recall that you need a minimum of a 100 Mbps to run any VLAN trunking protocol. If you 
do not have routers with 100-Mbps interfaces, routing also can be accomplished by 
configuring three Ethernet interfaces to the switch from a single router; one interface 
would be in each VLAN. 

Three Cisco Catalyst Ethernet switches. This lab was designed specifically for two Catalyst 
2900/3500 series switches and one Catalyst 4000/5500/6500 series switch. 

To gain practical experience on each type of Cisco Catalyst platform, both types of 
switches are used in this lab. The gl_switch1 is in the Catalyst 4000/5500/6500 family, 
while the gl_switch2 and gl_switch3 are in the Catalyst 2900/3500 series family. The 
specific type of switch is not that important to the functionality of this lab. 


Physical Layout and Prestaging 


The networks 172.16.20.0/24 and 172.16.21.0/24 are simulated by loopback interfaces on 
the glaccess_ 2 and glaccess 1 routers, respectively. 

This chapter does not focus on the EIGRP and HSRP configurations of this lab. We will 
show how they are performed during the walkthrough, but for more information on the 
specifics of how to configure EIGRP and HSRP, see the chapters covering that material. 
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Lab 7: Ethernet Switching, VLAN Trunking, and Spanning Tree 
Root Placement—Part Il 


Lab Walkthrough 


Attach the switches by using Cat 5 Ethernet crossover cables. A switch in a back-to-back 
mode requires a crossover cable. Attach the routers with Cat 5 patch cables to the switches, 


as illustrated in Figure 2-39. 


In building this model, you will begin with the configuration of the Ethernet switches and end 
with the configuration of the routers. Let's begin by defining VLANs and IP subnets to them. 
Figure 2-40 more accurately reflects the network VLANs, HSRP, and IP address at this point. 


Figure 2-40. Game LAN Ethernet Network 
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You also need to define and create the following VLANs: 


e VLAN 1— You will not use this VLAN. 

e VLAN 16— IP subnet 172.16.16.0/24. 

e VLAN 17— IP subnet 172.16.17.0/24. 

e VLAN 128— IP subnet 172.16.128.0/24 (new management VLAN). 


The VLAN IDs do not need to match the subnet; we purposely match the VLAN ID to the 
subnet to make the network more self-documenting. 


You will begin by configuring the gl_switch1 device. In this model, this device is a Catalyst is 
in the 4000/5500/6500 family. Recall the four-step configuration process from earlier in this 
chapter: 


Step 1. Configure switch management. 
Step 2. Configure VTP and VLANs. 
Step 3. Configure VLAN trunks, if applicable. 


Step 4. Optional: Control STP and VLAN propagation. 


Step 1 calls you to configure basic switch management. Because you are not using VLAN 1 as 
the default VLAN, you will need to create a new default VLAN before configuring the 
management interface. To allow IP access to the switch, you also need to configure a 
password. Example 2-47 demonstrates the creation of the VTP domain, VLANs, and the new 


management interface on gl_ switchl. 


Example 2-47 Initial Configuration gl_ switch1 


Console> (enable) set prompt gl_switchl 

gl_switchl (enable) set vtp domain funtime 

VTP domain funtime modified 

gl_switchl (enable) set vlan 16 

Vlan 16 configuration successful 

gl_switchl (enable) set vlan 17 

Vlan 17 configuration successful 

gl_switchl (enable) set vlan 128 name management 

Vlan 128 configuration successful 

gl_switchl (enable) 

gl_switchl (enable) set int scO 128 172.16.128.13 255.255.255.0 
Interface sc0O vlan set, IP address and netmask set. 
gl_switchl (enable) set ip route 0.0.0.0 172.16.128.1 
Route added. 

gl_switchl (enable) 
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Example 2-47 also shows the addition of a default route. The set ip route 0.0.0.0 
172.16.128.1 command causes the switch to forward all IP traffic to this address. This 
address needs to be on the same subnet as the management interface—in this case, subnet 
172.16.128.0/24. 


To ensure that the VTP domain is active, use the show vtp domain command to check for 
configuration errors. 


You already have begun to configure the first phase of Step 2, and normally you still would 
need to assign ports to VLANs. This switch, however, doesn't have any ports in VLANs to 
configure. This switch has only trunks to the other switches. Therefore, you can skip to Step 3 
and define the trunks. To configure the trunks, set them to a static 802.1q trunking mode. 
Example 2-48 demonstrates the configuration of the trunk lines on gl_ switchl. 


Example 2-48 Trunk Configuration on gl_ switch1 


gl_switchl (enable) set trunk 2/1 dotlq 
Port(s) 2/1 trunk type set to dotlq. 
gl_switchl (enable) set trunk 2/1 on 
Port(s) 2/1 trunk mode set to on. 
gl_switchl (enable) set trunk 2/14 dotlq 
Port(s) 2/14 trunk type set to dotlq. 
gl_switchl (enable) set trunk 2/14 on 
Port(s) 2/14 trunk mode set to on. 
gl_switchl (enable) set trunk 2/20 dotlq 
Port(s) 2/20 trunk type set to dotlq. 
gl_switchl (enable) set trunk 2/20 on 
Port(s) 2/20 trunk mode set to on. 
gl_switchl (enable) 


The final step calls for you to fine-tune Spanning Tree. This step cannot be completed until all 
the trunks are up and operational. When the entire network is converged, routers included, 
you can come back and tune STP on all the switches. For now, configure the rest of the 
switches in the domain. The initial configurations of the gl_switch2 and the gl_switch3 are 
similar. Beginning with other VTP server, gl_switch2, configure basic management. Example 
2-49 demonstrates the configuration of the management interface on gl_switch2. Remember, 
the gl_switch2 and gl_switch3 devices are in the Catalyst 2900/3500 family, so their 
configuration is different from that of the gl_switch1 device. 


Example 2-49 Management Configuration on gl_ switch2 


Switch (config) #hostname gl_switch2 

gl_switch2 (config) #int vlanl 

gl_switch2 (config-if) #shut 

gl_switch2 (config-if) #exit 

01:35:54: SLINK-5-CHANGED: Interface VLAN1, changed state to administratively do 
wn 

01:35:55: SLINEPROTO-5-UPDOWN: Line protocol on Interface VLAN1, changed state t 
gl_switch2 (config) #int vlan128 

gl_switch2 (config-subif) #ip address 172.16.128.11 255.255.255.0 

gl_switch2 (config-subif) #no shut 

gl_switch2 (config-if) #exit 

gl_switch2 (config) #ip default-gateway 172.16.128.1 
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To allow IP connectivity to the switch, a default- gateway had to be configured, as in Example 
2-48. The default gateway must be in the same subnet as the current active management 
interface, VLAN 128. The IP address of the gateway is the HSRP address of 172.16.128.1. 


In Step 2, you define the VTP domain and VLANs. Because you already have VLANs defined 
on the gl_switchl1, there is no need to configure VLANs on any more switches; instead, you 
can rely on VTP to transport the VLAN information after the trunks are up. Example 2-50 
demonstrates the configuration of the VTP domain on gl_switchl. 


Example 2-50 VTP Domain Creation on gl_ switch2 


gl_switch2#vlan database 
gl_switch2 (vlan) #vtp domain funtime 
Changing VIP domain name from cisco to funtime 


The gl_switch2 device has a user VLAN on interface fastEthernet 0/7. To assign interface 
fastEthernet 0/7 to VLAN 16, use the switchport command, as in Example 2-51. 


Example 2-51 Assign an Interface to a VLAN on gl_ switch2 


gl_switch2#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
gl_switch2 (config) #interface fastEthernet 0/7 

gl_switch2 (config-if) #switchport mode access 

gl_switch2 (config-if) #switchport access vlan 16 


Proceeding on to Step 3, you can configure the trunks from this switch to the other two. The 
trunk to gl_ switch is an 802.1q trunk, while the trunks to gameserver_2 and gl_ switch3 are 
ISL. Example 2-52 demonstrates the configuration of these trunks on the gl_ switch2. 


Example 2-52 Assign an Interface to a VLAN on gl_ switch2 


Enter configuration commands, one per line. End with CNTL/Z. 
gl_switch2 (config) #int gig 0/1 

gl_switch2 (config-if) #switchport mode trunk 

gl_switch2 (config-if) #switchport trunk encapsulation dotiq 
gl_switch2 (config-if) #exit 

gl_switch2(config)#int fast 0/10 

gl_switch2 (config-if) #switchport mode trunk 

gl_switch2 (config-if) #switchport trunk encapsulation isl 
gl_switch2 (config-if) #exit 

gl_switch2(config)#int fast 0/20 

gl_switch2 (config-if) #switchport mode trunk 

gl_switch2 (config-if) #switchport trunk encapsulation isl 


When the trunks are configured on gl_switch2, the trunk to gl_switchl becomes active. To 
determine the status of the trunk, use the show vlan command along with show interface 
gigabitEthernet 0/ 1 switchport on gl_ switch2. The trunk should be up and trunking. You 
also should see the VLANs that you created on gl_switch1, and you should be able to ping 
the IP address of 172.16.128.13. Example 2-53 shows the status of an active trunk on 
gl_switch2. 
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Example 2-53 Verifying VLAN and Trunk Operation on gl_ switch2 


gl_switch2#show vlan 

VLAN Name Status Ports 

1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4, 
Fa0/5, Fa0/6, Fa0/8, Fa0/9, 
Fa0/11, Fa0/12, Fa0/13, Fa0/14, 
Fa0/15, Fa0/16, Fa0/17, Fa0/18, 
Fa0/19, Fa0/21, Fa0/22, Fa0/23, 
Fa0/24, Fa0/25, Fa0/26, Fa0/27, 
Fa0/28, Fa0/29, Fa0/30, Fa0/31, 
Fa0/32, Fa0/33, Fa0/34, Fa0/35, 
Fa0/36, Fa0/37, Fa0/38, Fa0/39, 
Fa0/40, Fa0/41, Fa0/42, Fa0/43, 
Fa0/44, Fa0/45, Fa0/46, Fa0/47, 
Fa0/48, Gi0/2 


16 VLANO0016 active Fa0/7 
Ly VLANO017 active 
128 management active 
1002 fddi-default active 
1003 token-ring-default active 
1004 fddinet-default active 
1005 trnet-default active 


<<<text omitted>>> 

gl_switch2# 

gl_switch2#show interface gigabitEthernet 0/1 switchport 
Name: Gi0/1 

Switchport: Enabled 

Administrative mode: trunk 

Operational Mode: trunk 

Administrative Trunking Encapsulation: dotlq 
Operational Trunking Encapsulation: dotlgq 
Negotiation of Trunking: Disabled 

Access Mode VLAN: 0 ((Inactive) ) 

Trunking Native Mode VLAN: 1 (default) 
Trunking VLANs Enabled: ALL 

Trunking VLANs Active: 1,16,17,128 

Pruning VLANs Enabled: 2-1001 


Priority for untagged frames: 0 
Override vlan tag priority: FALSE 
Voice VLAN: none 

Appliance trust: none 

gl_switch2# 


You will come back and complete Step 4, tuning STP, after you configure the gl_ switch3 
switch. 


Basic management configuration of the gl_switch3 switch is identical to the configuration in 
Example 2-49. In that example, you configured a host name, a management interface, and a 
default gateway. The VTP mode will be transparent, so there is not need to configure VLANs 
on this switch. The VLANs will be sent when the trunks are configured to the other two 
switches. Example 2-54 demonstrates the configuration of the VTP and trunks on gl_ switch3. 
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Example 2-54 VTP Client and VLAN Trunk Configuration on gl_ switch3 


gl_switch3#vlan database 
gl_switch3(vlan)#vtp domain funtime 
Changing VIP domain name from Null to funtime 


Setting device to VTP CLIENT mode. 
gl_switch3 (vlan) #exit 
gl_switch3#conf t 
Enter configuration commands, one per line. End with CNTL/Z. 
‘~ trunk configuration 


gl_switch3 (config-if) #switchport mode trunk 
gl_switch3(config-if) #switchport trunk encapsulation dotlq 
gl_switch3 (config-if) #exit 

gl_switch3 (config) #interface fastEthernet 0/20 

gl_switch3 (config-if) #switchport mode trunk 

gl_switch3 (config-if) #switchport trunk encapsulation isl 
gl_switch3 (config-if) #exit 


‘user port configuration 
gl_switch3(config-—if) #switchport mode access 
gl_switch3 (config-if) #switchport access vlan 17 


To verify the configuration, view the VTP status with the show vtp status command. You 
also can view the VLANs to be sure that they are being propagated. Example 2-55 lists the 
output of these status commands on the gl_ switch3. At this time, you also should be able to 
ping the IP addresses of the neighboring switches. 


Example 2-55 Verifying VTP Status on gl_ switch3 


gl_switch3#show vtp status 


VIP Version e 2 

Configuration Revision 7 4 

Maximum VLANs supported locally : 254 

Number of existing VLANs £8 

VIP Operating Mode : Client 

VTP Domain Name : funtime 

VTP Pruning Mode : Disabled 

VIP V2 Mode : Disabled 

VIP Traps Generation : Disabled 

MD5 digest : OxC9 OxC8 O0x2D OxEE Ox8D OxE1l 0x46 0x97 


Configuration last modified by 172.16.128.13 at 7-2-01 14:43:56 


gl_switch3# show vlan 

VLAN Name Status Ports 

i! default active Fa0/1, Fa0/2, Fa0/3, Fa0/4, 
Fa0/5, Fa0/7, Fa0/8, Fa0/9, 
Fa0/10, FaO/1l1, Fa0/12, Fa0/13, 
Fa0/14, Fa0/15, Fa0/16, Fa0/17, 
Fa0/18, Fa0/19, Fa0/22, Fa0/23, 
Fa0/24, Fa0/25, Fa0/26, Fa0/27, 
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Fa0/28, Fa0/29, Fa0/30, Fa0/31, 
Fa0/32, Fa0/33, Fa0/34, Fa0/35, 
Fa0/36, Fa0/37, Fa0/38, Fa0/39, 
Fa0/40, Fa0/41, Fa0/42, Fa0/43, 
Fa0/44, Fa0/45, Fa0/46, Fa0/47, 
Fa0/48, Gi0/1, Gi0/2 


16 VLANO016 active 

17 VLANOO17 active Fa0/6 

128 management active 

1002 fddi-default active 

1003 token-ring-default active 

1004 fddinet-default active 

1005 trnet-default active 

VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Transl Trans2 
al enet 100001 1500 -= = - = = 0 0 
LG enet 100016 1500: = = - 7 = 0 ) 
ale enet 100017 1500. = = = = = ) ) 
128 enet 100128 1500 - - - - - 0 ) 
1002 fddi 101002 1500 = 0 - = - ) ) 
TIO eae 101003 1500: = 0 - - srb 0 0 
1004 fdnet 101004 1500 <= 7 - ieee —- 0 0 
1005 trnet 101005 1500 <= - - bm = 0 ) 


gl_switch3# 
gl_switch3#ping 172.16.128.13 


Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.128.13, timeout is 2 seconds: 


Success rate is 100 percent (5/5), round-trip min/avg/max = 7/7/8 ms 
gl_switch3#ping 172.16.128.11 


Typ scape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.128.11, timeout is 2 seconds: 


Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/3 ms 
gl_switch3# 


The entire switching domain is operational at this point. All the switches will be capable of 
pinging each other's management interface. 


The two routers glaccess_1 and glaccess_2 should be configured for IP now. This involves 
simply configuring an IP addresses under the Ethernet interface and the loopback interface. 
In this model, you are using EIGRP as the routing protocol with an Autonomous System ID of 
2001. EIGRP must be configured on all the routers. Example 2-56 illustrates the configuration 
of glaccess_1. The configurations of glaccess_1 and glaccess_ 2 will be similar except for the 
IP addresses. 


Example 2-56 Router Configuration of glaccess_ 1 


hostname glaccess_1 
! 
interface Loopback20 
ip address 172.16.21.6 255.255.255.0 
no ip directed-broadcast 
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! 
interface Ethernet0 

ip address 172.16.17.6 255.255.255.0 
no ip directed-broadcast 

! 
<<<text omitted>>> 

! 

router eigrp 2001 

network 172.16.0.0 


no auto-summary 
! 


For the VLANs to communicate with one another, you must configure a router with an 
interface in each VLAN, or a router with a VLAN trunk. In this model, you will use the routers 
gameserver_1 and gameserver_2 to not only route between our VLANs, but also to provide 
resiliency through HSRP. When configuring a VLAN trunk, you need to create subinterfaces on 
the Ethernet interface and assign a VLAN and VLAN encapsulation to it. You will need one 
subinterface for each VLAN that you want to route between. Example 2-57 highlights the 
VLAN trunk configuration for both routers. The trunk of gameserver_1 is an 802.1 trunk, and 
the trunk of gameserver_2 is an ISL trunk. 


Example 2-57 Router Configuration of gameserver_1 and 
gameserver_2 


hostname gameserverl 

! 

interface FastEthernet0/0 

no ip address 

duplex auto 

speed auto 

! 

interface FastEthernet0/0.1 
encapsulation dot1Q 128 

ip address 172.16.128.14 255.255.255.0 
! 

interface FastEthernet0/0.2 
encapsulation dot1Q 16 

ip address 172.16.16.14 255.255.255.0 
! 

interface FastEthernet0/0.3 
encapsulation dot1Q 17 

ip address 172.16.17.14 255.255.255.0 


hostname gameserver_2 

! 

interface FastEthernet0/0 
no ip address 

duplex auto 

speed auto 

! 

interface FastEthernet0/0.1 
encapsulation isl 128 

ip address 172.16.128.10 255.255.255.0 
no ip redirects 

! 

interface FastEthernet0/0.2 
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encapsulation isl 16 

ip address 172.16.16.10 255.255.255.0 
no ip redirects 

! 

interface FastEthernet0/0.3 
encapsulation isl 17 

ip address 172.16.17.10 255.255.255.0 


no ip redirects 
! 


The HSRP configuration requires that the primary router for VLAN 128 and VLAN 17, subnets 
172.16.128.0/24 and 172.16.17.0/24, reside on gameserver_1. The HSRP primary address 
for VLAN 16, subnet 172.16.16.0/24, resides on gameserver_2. To accomplish this, you will 
need to create an HSRP group for every VLAN, for a total of three groups. You will use a 
priority of 101 for the interfaces that you want to be active. For more detailed information on 
configuring HSRP, see Chapter 16, "Configuring Hot Standby Routing Protocol (HSRP)." 


Example 2-58 lists the HSRP configuration of the gameserverl and gameserver2 routers. 


Example 2-58 HSRP Configuration of gameserverl and gameserver2 


hostname gameserverl 
! 
interface FastEthernet0/0 
no ip address 
duplex auto 
speed auto 
! 
interface FastEthernet0/0.1 
encapsulation dot1Q 128 
ip address 172.16.128.14 255.255.255.0 
standby 1 priority 101 preempt 
standby 1 ip 172.16.128.1 
! 
interface FastEthernet0/0.2 
encapsulation dot1Q 16 
ip address 172.16.16.14 255.255.255.0 
standby 2 priority 95 preempt 
standby 2 ip 172.16.16.1 
! 
interface FastEthernet0/0.3 
encapsulation dot1Q 17 
ip address 172.16.17.14 255.255.255.0 
standby 3 priority 101 preempt 
standby 3 ip 172.16.17.1 
! 


! 
hostname gameserver_2 

! 

interface FastEthernet0/0 
no ip address 

duplex auto 

speed auto 

! 

interface FastEthernet0/0.1 
encapsulation isl 128 
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ip address 172.16.128.10 255.255.255.0 
no ip redirects 

standby 1 priority 95 preempt 

standby 1 ip 172.16.128.1 

! 

interface FastEthernet0/0.2 
encapsulation isl 16 

ip address 172.16.16.10 255.255.255.0 
no ip redirects 

standby 2 priority 101 preempt 
standby 2 ip 172.16.16.1 

! 

interface FastEthernet0/0.3 
encapsulation isl 17 

ip address 172.16.17.10 255.255.255.0 
no ip redirects 

standby 3 priority 95 preempt 

standby 3 ip 172.16.17.1 


The network is fully redundant and operational now. All 1P addresses should be reachable. 
You can test the network with pings and by unplugging the gameserver_1 or gameserver_2 
routers. The network should experience no outages. Example 2-59 lists the route table of 


glaccess_1, showing the redundant routes. 


Example 2-59 The IP Route Table of glaccess_ 1 


glaccess_l#show ip route 
Codes: C -—- connected, S - static, I - IGRP, R - RIP, M —- mobile, B - BGP 
D — EIGRP, EX - EIGRP external, O - OSPF, IA —- OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area 
* — candidate default, U - per-user static route, o -— ODR 
P -— periodic downloaded static route 


Gateway of last resort is not set 


172.16.0.0/24 is subnetted, 5 subnets 


D 172.16.128.0 [90/284160) via 1T72.16617.10;, 01:04:35, Bthernetd 
[90/284160] via 172.16.17.14, 01:04:35, Bthernetd 

D 172.16.20.0 [90/412160] via 172.16.17.10, 01:04:35, Ethernet0 
[90/412160] via 172.16.17.14, 01:04:35, Ethernet0O 

Cc 172.16.21.0 is directly connected, Loopback20 

D 172.16.16.0 [90/284160] via 172.16.17.10, 01704:35, Bthernetd 
[90/284160] via 172.16.17.14, 01:04:35, Ethernet0O 

Cc 172.16.17.0 is directly connected, Ethernet0O 


glaccess_1l# 


The final steps in this lab involve setting Spanning Tree root and controlling IP access. To set 
STP root on the gl_switch1, you will use the set spantree root command. By viewing the 
current STP topology on the gl_switch3, you can see that it is currently root. Example 2-60 
shows the STP topology on gl_ switch3. 


Example 2-60 STP Topology on gl_ switch3 
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gl_switch3#show spanning-tree vlan 128 


Spanning tree 128 is executing the IEEE compatible Spanning Tree protocol 
Bridge Identifier has priority 32768, address 0004.275e.f0cl1 
Configured hello time 2, max age 20, forward delay 15 
We are the root of the spanning tree 
Topology change flag not set, detected flag not set, changes 2 
Times: hold 1, topology change 35, notification 2 
hello 2, max age 20, forward delay 15 
Timers: hello 1, topology change 0, notification 0 


Interface Fa0/20 (port 34) in Spanning tree 128 is FORWARDING 
Port path cost. 19, Port priority 128 
Designated root has priority 32768, address 0004.275e.f0cl1 
Designated bridge has priority 32768, address 0004.275e.f£0cl1 
Designated port is 34, path cost 0 
Timers: message age 0, forward delay 0, hold 0 
BPDU: sent 1376, received 0 


Interface Fa0/21 (port 35) in Spanning tree 128 is FORWARDING 
Port path cost 19, Port priority 128 
Designated root has priority 32768, address 0004.275e.f0cl1 
Designated bridge has priority 32768, address 0004.275e.f£0cl1 
Designated port is 35, path cost 0 
Timers: message age 0, forward delay 0, hold 0 
BPDU: sent 1392, received 2 

gl_switch3# 


You will want to set the gl_switch1 switch to be root for VLANs 17 and 128 only. Example 2- 
61 demonstrates the configuration of gl_switch1. 


Example 2-61 Setting Root for VLAN 17 and VLAN 128 on gl_ switch1 


gl_switchl (enable) set spantree root 17,128 

VLANs 17,128 bridge priority set to 8192. 

VLANs 17,128 bridge max aging time set to 20. 

VLANs 17,128 bridge hello time set to 2. 

VLANs 17,128 bridge forward delay set to 15. 

Switch is now the root switch for active VLANs 17,128. 
gl_switchl (enable) 


If you view STP on the gl_switch3 in Example 2-62, you will see that this switch is no longer 


root for VLAN 128. Notice that the priority has changed and that it now points to gl_switch1 
as the root. 


Example 2-62 STP for VLAN 128 


gl_switch3#show spanning-tree vlan 128 


Spanning tree 128 is executing the IEEE compatible Spanning Tree protocol 
Bridge Identifier has priority 32768, address 0004.275e.f0cl 
Configured hello time 2, max age 20, forward delay 15 
Current root has priority 8192, address 0030.1976.4d7£ 
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Root port is 35, cost of root path is 19 
Topology change flag not set, detected flag not set, changes 5 
Times: hold 1, topology change 35, notification 2 
hello 2, max age 20, forward delay 15 
Timers: hello 0, topology change 0, notification 0 


Interface Fa0/20 (port 34) in Spanning tree 128 is BLOCKING 
Port path cost. 19, Port priority 129 
Designated root has priority 8192, address 0030.1976.4d7f£ 
Designated bridge has priority 32768, address 0004.275e.f£5c3 
Designated port is 34, path cost 4 
Timers: message age 3, forward delay 0, hold 0 
BPDU: sent 4762, received 97 


Interface Fa0/21 (port 35) in Spanning tree 128 is FORWARDING 
Port path cost 19, Port priority 128 
Designated root has priority 8192, address 0030.1976.4d7f£ 
Designated bridge has priority 8192, address 0030.1976.4d7f£ 
Designated port is 84, path cost 0 
Timers: message age 3, forward delay 0, hold 0 
BPDU: sent 4777, received 98 

gl_switch3# 


To set the STP root for VLAN 16 on gl_ switch2, use the following global command: 


gl_switch2 (config) #spanning-tree vlan 16 priority 100 


If you exclude the VLAN, all VLANs will have a priority of 100. 


The final portion of the lab requires you to limit Telnet access to gl_switch1 to only devices on 
the subnet 172.16.17.0/24. This can be done by enabling IP permit lists. After an IP permit 
list is entered, it still must be enabled before it will take effect. Example 2-63 demonstrates 


the configuration of the IP permit list on gl_switchl1. 


Example 2-63 Enabling IP Permit Lists 


gl_switch1l (enable) set ip permit 172.16.17.0 255.255.255.0 
172.16.17.0 with mask 255.255.255.0 added to IP permit list. 
gl_switch1l (enable) set ip permit enable 

IP permit list enabled. 

gl_switchl (enable) 


The optional portion of the lab is about security. By enabling port security, you can force a 
port to become inactive if it detects a MAC address that isn't specifically allowed on that port. 
If port security is enabled when a workstation is plugged into the port, it automatically 
records the MAC address and secures the port for that address. To configure a specific 
address. add the MAC address to the set port security command. Example 2-64 


demonstrates enabling port security. 


Example 2-64 Enabling Port Security 


gl_switchl (enable) set port security 2/24 enable 00-00-86-3c-—3b-41 
Port 2/24 port security enabled with 00-00-86-3c-3b-41 as the secure mac address 
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Trunking disabled for Port 2/24 due to Security Mode 
gl_switchl (enable) 


If any other workstation or device is plugged into port 2/24, the port automatically shuts 
down. Example 2-65 highlights the port status after an unauthorized device is plugged into 


port 2/24. 


Example 2-65 Port Security 


gl_switchl (enable) show port 2/24 


Port Name Status Vlan Level Duplex Speed Type 
a Oa rae eee 
Port Security Secure-Src-Addr Last-Sre-Addr Shutdown Trap IfIndex 
“2/24 enabled 00-00-86-3c-3b—41 00-60-Sc-£3-5e-65 Yes disabled 34. 
Port Status Channel Channel Neighbor Neighbor 

mode status device port 
Ceci ome eeseuemet “9° °° = = = = °° 


<<<text omitted>>> 
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Lab 8: Configuring Token Ring Switching Using the Catalyst 3920— 
Part | 


Practical Scenario 


Token Ring LANs are the second most popular type of network found in modern data centers. 
Most data centers that have SNA mainframes still have Token Ring networks in place. The 
following lab gives you practice in configuring Token Ring switching. Throughout the rest of this 
text, you are encouraged to use Token Ring switches, if you have them available, to enhance the 
labs on routing protocols and feature sets. 


Lab Exercise 


Game LANs, Inc., the same company that provides high-speed Ethernet LANs for entertainment 
centers around the country, also provides Token Ring LANs. One of Game LANs' customers is a 
small group of people still devoted to playing DOOM on their Token Ring PS/2 PCs. They currently 
have two Token Ring networks with two IP subnets that they want moved to a switched 
environment. 


Your task is to configure a Game LAN network by using the following parameters as design 
guidelines: 


e Configure a Token Ring switched network as depicted in Figure 2-41. 


Figure 2-41. Game LAN Token Ring Network 
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Use the VTP domain "rings" and set the switch to be a VTP server. 

Create two VLANs, one for subnet 128.100.1.0/24 and one for 128.100.2.0/24. 

Configure ports 3-24 to be in the VLAN that contains the subnet 128.100.2.0/24. 
Configure IP routing for the network so that there is full IP connectivity to all workstations, 
routers, and switches. Use RIP as the routing protocol for the internetwork. 


Lab Objectives 


e Configure a Token Ring switched network as depicted in Figure 2-41. 
Use the VTP domain "rings," and set the switch to be a VTP server. Create two VLANs, one 
for subnet 128.100.1.0/24 and one for 128.100.2.0/24. The actual configuration might 
require more VLANs than this. 

e Configure ports 3 to 24 to be in the VLAN that contains the subnet riche 


e Configure the switch with the IP address as shown in the diagram. 


e Use RIP as the routing protocol for the internetwork. Ensure full |P connectivity between 
all workstations, routers, and switches. 


Equipment Needed 


e Two Cisco routers with Token Ring interfaces. One router must have two Token Ring 
interfaces. 


e One Catalyst 3920 Token Ring Switch. 


e The workstation(s) in the diagram are for extra testing and are not a necessary part of this 
lab. 


Physical Layout and Prestaging 


e Connect the switches and the routers, as shown in Figure 2-41. 


e The workstation is optional but is recommended to enhance testing and the functionality of 
network. 
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Lab 8: Configuring Token Ring Switching Using the Catalyst 3920 
—Part Il 


Lab Walkthrough 


Attach the routers to the switch with Cat 5 patch cables, as illustrated in Figure 2-41. When 
the physical hardware is properly attached, you can begin to follow the six steps for 
configuring Token Ring switching: 

Step 1. Plan TrBRFs, TrCRFs, ring numbers, bridge numbers, and VLANs. 

Step 2. Configure VTP. 

Step 3. Configure TrBRF VLAN(s) and assign a bridge number to each TrBRF. 


Step 4. Configure TrCRFs VLANs and assign a parent TrBRF and an optional ring 
number. 


Step 5. Assign ports to TrCRFs. 

Step 6. Configure switch management. 
Figure 2-42 diagrams the VLANs that you will need to create. You will need to create two 
TrBRF VLANs and two TrCRF VLANs. Ports 3-24 will belong to TrCRF crf-ring8, with a parent 


TrBRF called brf8. Ports 1 and 2 will be in the TrCRF crf-ring10, with a parent TrBRF called 
brf10. 


Figure 2-42. TrBRF and TrCRF VLAN Conceptual Layout 
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The switch configuration will be performed entirely from the configuration panel, of the main 
menu. Step 1 is to configure the VTP domain. Select the VLAN and VTP configuration panel. 
This is where you will configure VTP and the VLANs needed. Figure 2-43 displays the 


configuration panel. 


Figure 2-43. Configuration Panel 
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From the VLAN and VTP configuration panel, select the VTP administrative configuration 
panel. Configure the VTP domain to be a server, and assign a name of rings to it. Figure 2-44 


displays this panel. 


Figure 2-44. VTP Administrative Panel 
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VTP Administrative Configuration 


Domain Name rings 
Local Hode Server 
Domain Password 


Domain Revision Number a 
lime of Last Revision Change OF /BS/61 81:58:71 
Last Updated By 8.8.8.8 


Step 3 involves configuring the TrBRFs. From the VLAN and VTP configuration panel, select 
the VTP VLAN configuration panel. From the VTP VLAN configuration panel select Add to add 
a new VLAN. The switch prompts you for a VLAN name. The first VLAN that you will create is 
brf8, VLAN 80. The switch then prompts you for whether the VLAN is a TrBRF or a TrCRF. 
When you select TrCRF, it takes you to the VLAN configuration menu. From this menu, name 
the VLAN brf8, and enter a ring number of 8. Remember to enter the ring number in 
hexadecimal format. Ring 10 will be entered as 0x0a when you configure that ring. Figures 2- 


45 and 2-46 display the VLAN configuration for TrBRFs. 


Figure 2-45. Detailed TrBRF VLAN Configuration 
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Figure 2-46. Detailed TrBRF VLAN Configuration 
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Enter Bridge Number 


The next step in the configuration is to configure the TrCRF VLANs. These are created from 
the same menu as the TrBRF VLANs. When you are prompted for the VLAN type, you 
obviously should select TrCRF instead of TrBRF. When creating the TrCRF VLANs, do not get 
the VLAN IDs confused. The VLAN IDs for the TrCRF and TrBRFs are unique. The TrCRF is 
linked to a TrBRF by making it a parent to TrCRF, not by the VLAN ID. Figures 2-47 and 2-48 
display the configuration of the TrCRFs VLANs. 


Figure 2-47. Detailed TrCRF VLAN Configuration 
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VLAN Parameter Configuration for TrCRF 
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Figure 2-48. Detailed TrCRF VLAN Configuration 
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Figure 2-49 displays the VTP VLAN configuration panel with the newly created VLANs. 


Figure 2-49. VLAN Listing 
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Step 5 involves assigning the ports to the TrCRFs just created. Ports 3 to 24 will be assigned 
to TrCRF crf-ring8, and ports 1 and 2 will be assigned to TrCRF crf-ring10. From the VLAN 
VTP configuration panel, select the Local VLAN port configuration option. From this panel, 
select the port that you want to modify. When the port is selected, the switch prompts you 
for what TrCRFs are available to attach the port to. Figure 2-50 displays this option. 


Figure 2-50. Port Configuration 
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Press <SPACE? to toggle, <M> for more, <RETURM> to exit selection menu. 


The final step in the configuration is to configure IP access. From the main configuration 


panel, select |P Configuration to configure an IP address. When this panel is selected, the 
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switch prompts you for a TrBRF to attach the IP address to. In this model, the IP address is 
128.100.2.99, so it will attach to TrBRF brf8. When in this menu, enter the IP information; 
use 128.100.2.1 for the default gateway. Figure 2-51 displays the IP configuration panel. 


Figure 2-51. IP Configuration 
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The IP interface will not become active until the same TrBRF becomes the default 
management interface. This is enabled through the SNMP configuration panel. From the 
SNMP configuration panel, change the management VLAN from the default to TrBRF brf8. 


The switches are fully operational now, and the routers can be configured. The router portion 
of the lab is rather straightforward. The doom1 router will have two Token Ring interfaces 
and will run RIP for a routing protocol. The doom2 router will need only one interface 
configured for IP. Example 2-66 illustrates the relevant configuration of the doom1 and 
doom2 routers. 


Example 2-66 Configurations of the doom1 and doom2 Routers 


hostname dooml 

! 

<<<text omitted>>> 

! 

interface TokenRingO 

ip address 128.100.1.1 255.255.255.0 
no ip directed—-broadcast 

ring-speed 16 

! 
interface TokenRingl 

ip address 128.100.2.1 255.255.255.0 
no ip directed—-broadcast 

ring-speed 16 
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! 
router rip 


network 128.100.0.0 
! 


! 
! hostname doom2 

! 
<<<text omitted>>> 

! 
interface TokenRingO 

ip address 128.100.1.3 255.255.255.0 
ring-speed 16 

! 

interface BRIO 

no ip address 

shutdown 

! 

router rip 


network 128.100.0.0 
! 


When the routers are configured, test the network by pinging all router and switch 
interfaces. The route table of the doom2 router also shows the subnet 128.100.2.0/24 being 


reported by RIP. 
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Part Ill: Connecting LANs with Wide-Area Networks 
(WANs) 


Chapter 3 WAN Protocols and Technologies: High-Level Data Link Control (HDLC) 


Chapter 4 WAN Protocols and Technologies: Point-to-Point Protocol (PPP) 


Chapter 5 WAN Protocols and Technologies: Frame Relay 


Chapter 6 WAN Protocols and Technologies: Voice over X 


Chapter 7 WAN Protocols and Technologies: Integrated Services Digital Network (ISDN) 


Chapter 8 WAN Protocols and Technologies: Asynchronous Transfer Mode (ATM) 


Part Ill Connecting LANs with Wide-Area Networks (WANs) 
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Chapter 3. WAN Protocols and Technologies: High- 
Level Data Link Control (HDLC) 


Wide-area networks evolved from the need to share data across vast geographical distances. 
The definition of WAN is a network spanning a wide geographic area. The purpose of the WAN 
is to connect local-area networks (LANs) and to transport data from one LAN to another. In 
our studies, the WAN is used much in the same way. 


WAN protocols have changed over time. At first, WAN protocols focused on error correction 
and were designed to operate on old, unreliable copper lines. WAN protocols today offer high- 
speed reliable transport on copper and fiber optic lines. Despite the vast evolution of the 
WAN, it still proves to be the slowest and most expensive part of any modern internetwork. 


WAN protocols function at the lower three layers of the OSI model. X.25 PLP is one of the 
protocols that operates at Layer 3, but most WAN protocols operate at Layer 2. Table 3-1 


displays some common WAN protocols and their corresponding layers in the OSI reference 
model. 


Table 3-1. WAN Protocols and Their Corresponding OSI Layers 


| OSI Layers WAN Protocols 
Network layer |X.25 PLP 


Data link Frame PPP |HDLC |X.25 |SDLC  |ATM-AAL 
Relay 
LAPB 


layer 
EIA/TIA-232 


Physical layer 


EIA/TIA-449 V.24, V.35, HSSI 


G703, EIA-530 


In the lab, using Cisco 2500 and 2600 series routers, you can readily model HDLC, PPP, 
Frame Relay, and X.25. Our studies start with these protocols and end with ISDN and ATM. 
Modeling ISDN and ATM requires the use of specialized routers and switches. 
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The Compatibility and Simplicity of HDLC 


High-Level Data Link Control (HDLC) is an efficient WAN protocol based primarily on IBM's 
Synchronous Data Link Control (SDLC) protocol. Cisco's version of HDLC is derived from the ISO 
3309 frame. Many forms of the HDLC frame exist, but Cisco's version is not compatible with any 
other vendors, such as Unisys's implementation of HDLC or the |SO 3309 frame. Even though these 
frames are similar, they are not compatible. 


Cisco's version of HDLC has the following characteristics: 


Incompatibility with other vendors 

Fast and efficient performance 

Support for a keepalive mechanism 

Support for the Serial Link Address Resolution Protocol (SLARP) 
Support for STAC compression 


HDLC is the default serial encapsulation, so it does not appear in the configuration listing; however, 
the HDLC encapsulation appears on the show interface display. 


The overhead associated with an HDLC frame is small—it has a beginning and ending Flag field, a 
varied Address field, a Control field, and a variable Information field. Even though these fields vary in 
size, they vary only from 1 to 4 bytes in length. The overhead of the whole frame ranges from 7 
bytes to 12 bytes, which is small. This is where HDLC gains its efficiency. 


The HDLC frame uses a keepalive mechanism to verify link integrity. The DCE side of the link sends a 
sequence number to the DTE side. The DTE side, in turn, sends this number back. The router knows 
that if it received its last sequence number echoed back from the DTE side of the link, the link is 
operational. If this sequence number is missed three times in a row, the router deactivates the link. 
In Example 3-1, you can observe a link going down by not having its keepalives echoed back. This 


data was displayed with the aid of the debug serial interface command. 


Example 3-1 Keepalives on an HDLC Frame Not Being Echoed Back 


06:35:59: SLINK-3-UPDOWN: Interface Seriall, changed state to up 


— 
06:36:00: SLINEPROTO-5-UPDOWN: Line protocol on Interface Seriall, changed state 
to up 
06:36:10: HD(1): Deasserting DSR, CTS and DCD 
06:36:10: HD(1): Reset from 0x3057C8C 
06:36:10: HD(1): Asserting DSR 
06:36:10: HD(1): Asserting DCD and CIs 
06:36:10: HD(1): Deasserting LTST 
06:36:10: HD(1): Asserting DTR and RTS 
“~ ka not received 


06:36:18: HD(0): New serial state = 0x0115 


06:36:18: HD(1): got an interrupt state = 0x8055 
06:36:18: HD(1): New serial state = O0Ox005F 


06336218: HDL): “DIR: 2S up 

06:36:20: HD(1): Deasserting DSR, CTS and DCD 
06:36:20: HD(1): Reset from 0x3057C8C 
06:36:20: HD(1): Asserting DSR 

06:36:20: HD(1): Asserting DCD and CTS 
06:36:20: HD(1): Deasserting LTST 

06:36:20: HD(1): Asserting DTR and RTS 


285 


_— 


06:36:21: SLINEPROTO-5-UPDOWN: Line protocol on Interface Seriall, changed state 
to down 
06:36:28: HD(0): New serial state = 0x0115 


06:36:28: HD(1): got an interrupt state = 0x8055 
06:36:28: HD(1): New serial state = Ox005F 


06:36:28: HD(1)% DIR is: up. 

06:36:30: Seriall: HDLC myseq 3, mineseen 0, yourseen 0, line down 
06:36:40: Seriall: HDLC myseq 4, mineseen 0, yourseen 0, line down 
06:36:50: Seriall: HDLC myseq 5, mineseen 0, yourseen 0, line down 
06:36:51: Seriall: attempting to restart 

06:36:51: HD(1): Deasserting DSR, CTS and DCD 

06:36:51: HD(1): Reset from 0x3057C8C 


Notice in Example 3-1 that the sequence number or the myseq field isn't incrementing and matching 
with the mineseen field. In a correctly operating link, the keepalives will be incrementing and sent to 
the downstream router. The router will receive these and send them back. The keepalives then show 
up in the mineseen field of the original router sending it. If the myseq field and mineseen field differ 
by 3, meaning that three keepalives were dropped, the router reinitializes the link. The yourseen field 
is the other router's keepalive mechanism and performs the same function. Example 3-2 corrects the 
problem; observe the debug output. 


Example 3-2 Debug Log of a Correctly Functioning HDLC Link 


06:49:30: Seriall: HDLC myseq 81, mineseen 0, yourseen 0, line down 
06:49:31: %SSYS-5-CONFIG_I: Configured from console by console 


_ 


06:49:41: SLINEPROTO-5-UPDOWN: Line protocol on Interface Seriall, changed state 
EO “Up 

06:49:50: Seriall: 
06:50:00: Seriall: 
06:50:10: Seriall: 
06:50:20: Seriall: 
06:50:31: Seriall: 
06:50:41: Seriall: 
v3 

06:50:51: Seriall: HDLC myseq 89, mineseen 89*, yourseen 89, line up 


DLC myseq 83, mineseen 83%, yourseen 83, line up 
DLC myseq 84, mineseen 84%, yourseen 84, line up 
DLC myseq 85, mineseen 85*, yourseen 85, line up 
DLC myseq 86, mineseen 86*, yourseen 86, line up 
DLC myseq 87, mineseen 87*, yourseen 87, line up 
DLC myseq 88, mineseen 88*, yourseen 88, line up 


The exchange of keepalives happens only when Layer 1 of the link is up. If DCD=up, DSR=up, 
DTR=up, RTS=up, and CTS=up are not present, there will be no keepalive exchanges present. 


HDLC also supports SLARP, which is used in the autoinstall process for a serial line to gain and 
dynamically map its |P address. The Cisco autoinstall process takes advantage of SLARP. 


Cisco's implementation of HDLC also supports payload compression by the use of the STAC 
compression algorithm. The STAC compression technique, developed by STAC Electronics, uses the 
Lempel-Ziv compression algorithm. This algorithm provides good compression but can use many CPU 
cycles to compress the payload of the frame. STAC compression also can be used with LAPB, X.25, 
and Frame Relay. 


TIP 


As a design rule, use HDLC encapsulation for simple configuration with fast, reliable 
performance between Cisco routers. 
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Configuring HDLC 


HDLC is the default frame encapsulation on all serial interfaces. Therefore, its configuration can be a 
simple three-step process: 


Step 1. Configure the encapsulation from the interface mode by using the encapsulation 
hdic command. 


Step 2. Configure the DCE side of the link by using the clock rate clock_speed command. 
This is used only in routers that are attached with back-to-back cables. When using CSU/ 
DSUs, the CSU is the DCE device. 


Step 3. (Optional) Configure compression on both ends of the link by using the compression 
stac command. 


If you were switching from Frame Relay or another encapsulation to HDLC, you would need to use 
the encapsulation hdlic statement from the interface configuration mode. You can also use the no 
form of the encapsulation statement, as in no encapsulation PPP. This returns the encapsulation 
type to the default, which is HDLC. If you are using back-to-back serial cables, or if the interface is 
cabled as a DCE, you will need to also add the clock rate xxxx statement in the interface 
configuration mode on the router with the DCE cable attached. If you want to use STAC compression, 
enter compression stac from the interface configuration mode. Compression must be added to both 
routers on the link. Make sure that you are aware of the caveats—that is, CPU usage—before 
implementing any compression technique. 


Figure 3-1 illustrates a basic HDLC network. The espn router has two serial connections, one to the 


atlanta router and one to the bristol_u router. Following the aforementioned multistep process for 
configuring HDLC, configure this basic HDLC network. To set the encapsulation to HDLC, use the 
interface command encapsulation hdlc on each side of the serial link. For the DCE sides on the link, 
on the espn router, you need to set the clock rate command under the serial interface. 


Figure 3-1. Basic HDLC Network 


espn 


atlanta T1 j 
HDLC =e ar ne bristol_u 
Sao ane te oe 
SO0-DTE $1-DCE $5-DCE S0-DTE 
IP-12.168.128.1/30 IP-12.168,128.2/30 IP-12.168.128.9/30 IP-12.168.128.10/30 


Example 3-3 demonstrates the HDLC configuration of the espn router. Assume that EIGRP as been 
configured as the routing protocol for the network. 


Example 3-3 HDLC Configuration of the espn Router 


espn (config) #interface sl 

espn (config-if) #encapsulation hdlc 

espn (config-if) #eclock rate 2000000 

espn (config-if)#ip address 12.168.128.2 255.255.255.252 
espn (config-if) #exit 

espn (config) # 

espn (config) #interface s5 

espn (config-if) #encapsulation hdlc 

espn (config-if) #clock rate 56000 

espn (config-if)#ip address 12.168.128.9 255.255.255.252 
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Example 3-4 demonstrates the HDLC configuration of the bristol_u router. 


Example 3-4 HDLC Configuration of the bristol_ u Router 


bristol_u 
bristol wu 
bristol 
bristol. .w 


config) #interface s0 

config-if) #encapsulation hdlc 

config-if)#ip address 12.168.128.10 255.255.255.252 
config-if) #exit 


~ nN On 


As you can see, the configuration of HDLC is straightforward. Most of the time, you will not even need 
to configure an encapsulation, but you will configure simply an IP address. 


The "Big show" and "Big D" for HDLC 


The show and debug commands used for HDLC can also be used on most serial interfaces. HDLC is 
a simple protocol. Therefore, the show and debug commands are limited but get the job done. 


The "big show" and the "big D" commands for HDLC are show interface serial_ interface and show 
controllers serial_interface. They're discussed next. 


show interface serial_interface Command 


The show interface serial_ interface command displays the operational status of an interface. The 
key fields are the interface line [up | down] and the line protocol [up | down]. These fields represent 
ISO Layer 1 and Layer 2, respectively. The encapsulation type also will be listed along with the 
keepalive value. DCD, DSR, DTR, RTS, and CTS should all read "up." The interface reset field tells 
how many times the link has reset itself. Other fields to note indicate the drops, frame, aborts, and 
CRC errors. Example 3-5 demonstrates output from this command. 


Example 3-5 Output of the show interface Command 


router#show interface serial 5 
Serial5 is up, line protocol is up 
Hardware is CD2430 in sync mode 
Internet address is 12.168.128.9/30 
MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255 
Encapsulation HDLC, loopback not set, keepalive set (10 sec) 
Last input 00:00:02, output 00:00:00, output hang never 
Last clearing of "Show interface" counters never 
Input queue: 0/75/0 (size/max/drops); Total output drops: 0 
Queuing strategy: weighted fair 
Output queue: 0/1000/64/0 (size/max total/threshold/drops) 
Conversations 0/1/256 (active/max active/max total) 
Reserved Conversations 0/0 (allocated/max allocated) 
5 minute input rate 0 bits/sec, 0 packets/sec 
5 minute output rate 0 bits/sec, 0 packets/sec 
3870 packets input, 206261 bytes, 0 no buffer 
Received 1524 broadcasts, 0 runts, O giants, 0 throttles 
OQ input errors, 0 CRC, 0 frame, O overrun, O ignored, 0 abort 
3907 packets output, 228500 bytes, O underruns 
0 output errors, 0O collisions, 44 interface resets 
QO output buffer failures, 0O output buffers swapped out 
24 carrier transitions 
DCD=up DSR=up DTR=up RTS=up CTS=up 
router# 


288 


show controllers serial_interface Command 


Use the show controllers serial_ interface command to gain physical layer information about a serial 
controller. This information also helps verify the cable type and whether it is DCE or DTE. Example 3- 


6 demonstrates output from this command. 


Example 3-6 Output of the show interface Command 


espn#show controllers serial 1 
HD unit 1, idb = O0xD7A28, 
buffer size 1524 HD unit 1, 
cpb = 0x43, eda = 0x2140, cda = 0x2000 

RX ring with 16 entries at 0x432000 

00 bd_ptr=0x2000 pak=0x0DF384 ds=0x43C468 
01 bd_ptr=0x2014 pak=0x0DF1B4 ds=0x43BDBO 
02 bd_ptr=0x2028 pak=O0x0DEFE4 ds=0x43B6F8 
03 bd_ptr=0x%203C pak=0x0DEE14 ds=0x43B040 
04 bd_ptr=0x2050 pak=0x0DEC44 ds=0x43A988 
05 bd_ptr=0x2064 pak=0x0DEA74 ds=0x43A2D0 
06 bd_ptr=0x2078 pak=0x0DE8A4 ds=0x439C18 
07 bd_ptr=0x208C pak=0x0DE6D4 ds=0x439560 
08 bd_ptr=0x20A0 pak=0x0DE504 ds=0x438EA8 
09 bd_ptr=0x20B4 pak=0x0DE334 ds=0x4387F0 
10 bd_ptr=0x20C8 pak=0x0DE164 ds=0x438138 
11 bd_ptr=0x20DC pak=0x0DDF94 ds=0x437A80 
12 bd_ptr=0x20F0 pak=0x0DDDC4 ds=0x4373C8 
13 bd_ptr=0x2104 pak=0x0DDBF4 ds=0x436D10 
14 bd_ptr=0x2118 pak=0x0DDA24 ds=0x436658 
15 bd_ptr=0x212C pak=0x0DD854 ds=0x435FA0 
16 bd_ptr=0x2140 pak=0x0DD684 ds=0x4358E8 
cpb = 0x43, eda = 0x2800, cda = 0x2800 

TX ring with 2 entries at 0x432800 

00 bd_ptr=0x2800 pak=0x000000 ds=0x000000 
01 bd_ptr=0x2814 pak=0x000000 ds=0x000000 
02 bd_ptr=0x2828 pak=0x000000 ds=0x000000 
QO missed datagrams, O overruns 
0 bad datagram encapsulations, 
QO transmitter underruns 

0 residual bit errors 


espn# 


debug serial interface Command 


status=80 
status=80 
status=80 
status=80 
status=80 
status=80 
status=80 
status=80 
status=80 
status=80 
status=80 
status=80 
status=80 
status=80 
status=80 
status=80 
status=80 


status=80 
status=80 
status=80 


0 memory errors 


driver structure at OxDC7A8 


V.35 DCE cable, clockrate 2000000 


pak_size=0 
pak_size=0 
pak_size=0 
pak_size=0 
pak_size=0 
pak_size=0 
pak_size=0 
pak_size=0 
pak_size=0 
pak_size=0 
pak_size=0 
pak_size=0 
pak_size=0 
pak_size=0 
pak_size=0 
pak_size=0 
pak_size=0 


pak_size=0 
pak_size=0 
pak_size=0 


Remember that, before you turn on debugs on you should always have the logging buffered 10000 
statement present in your configuration. This prevents a flood of console messages form tying up the 
console. 


To demonstrate the usefulness of these commands, we inserted faults into the previously mentioned 
lab. 


We will focus on troubleshooting one side of the problem at a time. Starting with the espn router, 
perform the show interface serial 5 command. Example 3-7 lists the output of the show interface 


command. 


Example 3-7 Output of the show interface Command 
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espn#show interface serial 5 


Hardware is CD2430 in sync mode 
Internet address is 12.168.128.9/30 
MTU 1500 bytes, BW 115 Kbit, DLY 20000 usec, rely 255/255, load 1/255 
Encapsulation HDLC, loopback not set, keepalive set (10 sec) 
Last input 00:00:02, output 00:00:00, output hang never 
Last clearing of "show interface" counters never 
Input queue: 0/75/00 (size/max/drops); Total output drops: 0 
Queuing strategy: weighted fair 
Output queue: 0/1000/64/0 (size/max total/threshold/drops) 
Conversations 0/1/256 (active/max active/max total) 
Reserved Conversations 0/0 (allocated/max allocated) 
5 minute input rate 0 bits/sec, 0 packets/sec 
5 minute output rate 0 bits/sec, 0 packets/sec 
3870 packets input, 206261 bytes, 0 no buffer 
Received 1524 broadcasts, 0 runts, O giants, O throttles 
OQ input errors, 0 CRC, 0 frame, O overrun, O ignored, 0 abort 
3907 packets output, 228500 bytes, O underruns 
0 output errors, 0 collisions, 174 interface resets 
QO output buffer failures, 0 output buffers swapped out 
24 carrier transitions 
DCD=up DSR=up DTR=up RTS=up CtTS=up 
espn# 


Notice that the line is up and the protocol is up. This is good indication that Layer 1 is working, and 
Layer 2 appears to be working. All the carrier signals show up as well, which is another indication that 
Layer 1 is working. The number of interface resets and carrier transitions looks suspicious, though. To 
see whether the counters are incrementing, clear the counters with the clear counters command. 
Then repeat the show interface command, and watch to see if they are incrementing. After 
performing this command, over a period of time, you will see that they do increment, indicating a 
potential link encapsulation problem. 


At this time, the physical aspects of the link to the bristol_u router seem to be working. If you 
performed the show controllers command, this would reaffirm that Layer 1 is operating normally. 
The problem seems to be a little bit deeper. Therefore, it is necessary to turn on debugs, as 
demonstrated in Example 3-8 with the debug serial interface command. In the preceding example, 
CIRRUS(5) represents serial interface 5, and HD(1) represents serial interface 1. HD and CIRRUS are 
controller cards for those ports. 


Example 3-8 Output of the debug serial interface Command 


eee | Lakin 
a ee ee oc eee) =6[ eae 
ee es 8=§=«Pasee nome mes 
Serial5, cd2430_sync_mode_init reinitializes 


-Traceback= 3078996 3078BEO 30C91DA 315F5BO 315F6E6 
CIRRUS (5): Deasserting DSR 


CIRRUS (5): Deasserting DCD 
CIRRUS (5): Deasserting CTS 
CIRRUS (5): Reset from 0x3078BD8 
CIRRUS (5): Asserting DSR 

CIRRUS (5): Asserting CTS 

CIRRUS (5): Asserting DCD 


Serial5: HDLC myseq 12, mineseen 0*, yourseen 12, line down 
SLINEPROTO-5-UPDOWN: Line protocol on Interface Serial5, changed state to down 


bicker aati met ie ana “Tt attempts to restart 
Gone Dee ee eee oeess 
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Serial5: HDLC mysegq 13, mineseen 0*, yourseen 13, line up 
SLINEPROTO-5-UPDOWN: Line protocol on Interface Serial5, changed state to up 
Serial5, cd2430_sync_mode_init 

-Traceback= 3078996 3078BEO 30C9200 315F5BO 315F6E6 

CIRRUS (5): Deasserting DSR 


CIRRUS (5): Deasserting DCD 
CIRRUS (5): Deasserting CTS 
CIRRUS (5): Reset from 0x3078BD8 
CIRRUS (5): Asserting DSR 

CIRRUS (5): Asserting CTS 

CIRRUS (5): Asserting DCD 


Serial5: HDLC mysegq 14, mineseen 0*, yourseen 14, line up 


The debugs confirm that an HDLC problem exists on the link, but on what side? Remember that the 
myseq field should equal the mineseen field. This means that a properly formatted HDLC frame was 
received and that the keepalive number removed and echoed back. 


Starting with the show interface command, observe the following about the bristol_u router in 
Example 3-9: 


Example 3-9 Output of the show interface command on bristol_u 


bristol_u#show interface serial 0 
SerialO is up, line protocol is down 
Hardware is HD64570 
Internet address is 12.168.128.10/30 
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255 
Encapsulation HDLC, loopback not set, keepalive set (10 sec) 
Last input 00:00:04, output 00:00:10, output hang never 
Last clearing of "show interface" counters never 
Queuing strategy: fifo 
Output queue 0/40, 44 drops; input queue 0/75, 0O drops 
5 minute input rate 0 bits/sec, 0 packets/sec 
5 minute output rate 0 bits/sec, 0 packets/sec 
4440 packets input, 258010 bytes, 0 no buffer 
Received 1954 broadcasts, 0 runts, O giants, 0 throttles 
OQ input errors, 0 CRC, 0 frame, O overrun, O ignored, 0 abort 
4271 packets output, 227876 bytes, O underruns 
0 output errors, 0 collisions, 63 interface resets 
0 output buffer failures, 0 output buffers swapped out 
497 carrier transitions 
DCD=up DSR=up DTR=up RTS=up CTS=up 


bristol_u#show interface serial 0 


Hardware is HD64570 
Internet address is 12.168.128.10/30 
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255 
Encapsulation HDLC, loopback not set, keepalive set (10 sec) 
Last input 00:00:00, output 00:00:01, output hang never 
Last clearing of "Show interface" counters never 
Queuing strategy: fifo 
Output queue 0/40, 44 drops; input queue 0/75, O drops 
5 minute input rate 0 bits/sec, 0 packets/sec 
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5 minute output rate 0 bits/sec, 0 packets/sec 
4450 packets input, 258590 bytes, 0 no buffer 
Received 1960 broadcasts, 0 runts, O giants, 0 throttles 
OQ input errors, 0 CRC, 0 frame, O overrun, O ignored, 0 abort 
4274 packets output, 227942 bytes, O underruns 


| 


DCD=up DSR=up DTR=up RTS=up CTS=up 
bristol_u# 


This time the line is up, but the line protocol is down. After waiting several seconds, and performing 
the same command, you see that the Interface Resets field and the Carrier transitions field are also 
incrementing. At this point, armed with the evidence of keepalives that are not being properly 
transmitted on one side and the line is up but the protocol is down, you have a clear indication of a 
Layer 2 HDLC problem. By listing the configuration on the bristol_u router, you find that HDLC 
compression was not enabled. Adding the compress stac statement to the Serial 0 interface of the 
bristol_u router, you can observe the line becoming active on the espn router. Example 3-10 


illustrates Serial 5 recovering on the espn router. 


Example 3-10 Output of the debug serial interface Command on espn 


Serial5: HDLC mysegq 165, mineseen 0*, yourseen 67, line down 
SLINEPROTO-5-UPDOWN: Line protocol on Interface Serial5, changed state to down 
Seriall: attempting to restart 

HD(1): Deasserting DSR, CTS and DCD 

HD(1): Reset from 0x304562A 

HD(1): Asserting DSR 

HD(1): Asserting DCD and CTS 

HD(1): Deasserting LTST 

HD(1): Asserting DTR and RTS 

Serial5: HDLC myseq 166, mineseen 166*, yourseen 68, line up 
SLINEPROTO-5-UPDOWN: Line protocol on Interface Serial5, changed state to up 
Serial5: HDLC mysegq 167, mineseen 167*, yourseen 69, line up 
Serial5: HDLC mysegq 168, mineseen 168*, yourseen 70, line up 
Seriall: attempting to restart 

HD(1): Deasserting DSR, CTS and DCD 

): Reset from 0x304562A 

): Asserting DSR 

): Asserting DCD and CTS 

): Deasserting LTST 

HD(1): Asserting DTR and RTS 

Serial5: HDLC mysegq 169, mineseen 169*, yourseen 71, line up 
Serial5: HDLC mysegq 170, mineseen 170*, yourseen 72, line up 
Serial5: HDLC myseg 172, mineseen 172*, yourseen 74, line up 
Serial5: HDLC mysegq 173, mineseen 173*, yourseen 75, line up 
Serial5: HDLC myseg 174, mineseen 174*, yourseen 76, line up 


1 
i, 


HD (1 
HD (1 
HD (1 
HD (1 


From the espn router, you can ping the bristol_u router and find that the link is up and fully 
functional. 


You can now focus on the problem in the atlanta router. In Example 3-11, start with the show 
interface serial 1 command: You see that the line is down and the line protocol is down. You should 
also see that the DTR and RTS signals are down. This immediately points to a Layer 1 problem. But 
which side is it on? When you perform the show controller serial 1 command on the espn router, 
all is normal—the controller reports no errors and also reports a V.35 DCE cable attached to the port. 
If you perform this same command on the atlanta router, you see that a serial cable is not detected. 
Example 3-11 demonstrates the show controller serial x command on both the espn and the 
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Example 3-11 Output from the show controllers Command Performed on 
the atlanta Router and the espn Router 


espn#show controllers serial 1 
HD unit 1, idb = OxD7A28, driver structure at 0xDC7A8 


cpb = 0x43, eda = 0x2140, cda = 0x2000 

RX ring with 16 entries at 0x432000 

00 bd_ptr=0x2000 pak=0x0DE8A4 ds=0x439C18 status=80 pak_size=0 
01 bd_ptr=0x2014 pak=0x0DDDC4 ds=0x4373C8 status=80 pak_size=0 
<<<text omitted>>> 

16 bd_ptr=0x2140 pak=0x0DD4B4 ds=0x435230 status=80 pak_size=0 
cpb = 0x43, eda = 0x2800, cda = 0x2800 

TX ring with 2 entries at 0x432800 

00 bd_ptr=0x2800 pak=0x000000 ds=0x000000 status=80 pak_size=0 
01 bd_ptr=0x2814 pak=0x000000 ds=0x000000 status=80 pak_size=0 
02 bd_ptr=0x2828 pak=0x000000 ds=0x000000 status=80 pak_size=0 
165 missed datagrams, 0 overruns 

0 bad datagram encapsulations, 0 memory errors 

QO transmitter underruns 

0 residual bit errors 


espn# 


atlanta# 

atlanta#show controller serial 0 

MK5 unit 0, NIM slot 0, NIM type code 7, NIM version 1 

idb = Ox60CF5DF8, driver structure at O0x60CFB100, regaddr = 0x3C000300 
IB at 0x40006E64: mode=0x0108, local_addr=0, remote_addr=0 

N1=1524, N2=1, scaler=100, T1=1000, T3=2000, TP=1 

buffer size 1524 


yo 


RX ring with 32 entries at Ox06EC8 : RLEN=5, Rxhead 0 
00 pak=0x60D0322C ds=0xA8214B44 status=80 max_size=1524 pak_size=0 
01 pak=0x60D02E44 ds=0xA8214488 status=80 max_size=1524 pak_size=0 
<<<text omitted>>> 
30 pak=0x60D03038 ds=0xA801449C status=80 max_size=1524 pak_size=0 
31 pak=0x60D02A5C ds=0xA8213DCC status=80 max_size=1524 pak_size=0 
TX ring with 32 entries at 0x07108 : TLEN=5, TWD=7 
tx_count = 0, tx_head = 0, tx_tail = 0 
00 pak=0x000000 ds=0xA8000000 status=0x38 max_size=1524 pak_size=0 
01 pak=0x000000 ds=0xA8000000 status=0x38 max_size=1524 pak_size=0 
<<<text omitted>>> 
30 pak=0x000000 ds=0xA8000000 status=0x38 max_size=1524 pak_size=0 
31 pak=0x000000 ds=0xA8000000 status=0x38 max_size=1524 pak_size=0 
XID/Test TX desc at OxFFFFFF, status=0x30, max_buffer_size=0, packet_size=0 
XID/Test RX desc at OxFFFFFF, status=0x0, max_buffer_size=0, packet_size=0 
Status Buffer at 0x40007340: rcv=0, tcv=0, local_state=0, remote_state=0 
phase=0, tac=0, currd=0x00000, curxd=0x00000 
bad_frames=0, frmrs=0, Tl_timeouts=0, rej_rxs=0, runts=0 
QO missed datagrams, O overruns 
0 bad datagram encapsulations, 0 memory errors 
QO transmitter underruns 
0 user primitive errors, 0 spurious primitive interrupts 
0 provider primitives lost, 0 unexpected provider primitives 
mk5025 registers: csr0O = 0x0E00, csrl = 0x0302, csr2 = 0x0500 
csr3 Ox6E64, csr4 0x0214, cesrd 0x0009 
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atlanta# 


After replacing the serial cable, the link becomes active and all is well again in the sports world. 
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Lab 9: Configuring HDLC—Part | 


Practical Scenario 


HDLC can have many uses in the field. One instance, as mentioned previously, is to always switch 
the encapsulation to HDLC when testing a CSU/DSU or an internal CSU/DSU with a loopback plug. 
HDLC is often used when connecting to a Cisco router administered by a third party. A third-party 
router is a router that is not part of your autonomous system or one that is not under your direct 
control. HDLC provides for a quick and easy configuration, minimizing the number of problems 
that can go wrong because of configuration errors. 


Lab Exercise 


In this exercise, you are a network engineer for ACME Finance. ACME Finance is about to have a 
new credit card authorization center and a Wisconsin branch join the network. The credit card 
center, cc_center, is running HDLC protocol on a 56-kbps link to your distribution router, 
acme_dist. The credit card center would like to improve performance on this link as soon as 
possible, by using payload compression. The Wisconsin branch router, wi_branch, has a T1 leased 
line into acme_dist router, but it is not configured. The WAN is the first circuit in each building, 
and there are no users; therefore, you won't be concerned with any LAN configurations. 


Lab Objectives 
e Configure the network as depicted in Figure 3-2. 


Figure 3-2. ACME Finance Network 


ACME Finance 


Chicago Disiniwiion Center 


Distribution Router: 


wi_branch T1 acme dist nl 
HDLC aI Tee oc_center 
00 ae OSS 
S0-DTE Si-DcE © $5-DCE S0-DTE 
IP-192.168.128.6/30 IP-192.168.128.5/90 IP-192.168.128.9/30 IP-192.168.128.10/30 


e Use only the HDLC protocol on the serial links. 
e Use payload compression on the 56-kbps link between the cc_center and acme_dist 
routers. 


Equipment Needed 


e Three Cisco routers. One must have two serial ports. 

e Four serial cables, preferably two V.35 DTE male and two V.35 DCE female cables. 
Otherwise, you can use the correct speed of CSU/DSUs with a crossover cable between 
them. When using actual CSU/DSUs, the clock rate interface command is not needed. 
For more information on the various ways to connect routers in a back-to-back manner, 
review Chapter 1, "The Key Components for Modeling an Internetwork." 


Physical Layout and Prestaging 
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e Connect the serial cables to the routers as shown in Figure 3-2. 
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Lab 9: Configuring HDLC—Part Il 


Lab Walkthrough 


Attach the serial cables as shown in Figure 3-2, ensuring that a DTE side is connected to a DCE side. 
If you forgot which side is which, perform the show controller command to show the cable type 
(DCE-DTE) attached to this interface. If the routers are connected in a back-to-back manner using 
serial cables, the clockrate command will be needed on the DCE side of the link. If the routers are 
connected using CSU/DSUs, the CSU/DSU is the DCE device, and the serial interface and cable to 
the CSU/DSU are DTE devices. Because configurations with CSU/DSUs are actually a DTE 
configuration to the router, you do not need to use the clock rate command. 


The distribution router, acme_dist, will be the DCE side of the link for both connections. To configure 
this router, perform the following: 


Step 1. (Optional) Configure a hostname of acme_dist. 


Step 2. Configure Serial 5 and Serial 1 for HDLC by using the Encapsulation hdlc 
statement. 


Step 3. Configure a clock rate on Serial 1 and Serial 5. 
Step 4. Configure STAC compression on Serial 1. 
Step 5. Configure an IP address for both serial interfaces. 


Step 6. (Optional) Configure a routing protocol. 


Example 3-12 demonstrates these steps. 


Example 3-12 Configure HDLC DCE Interfaces 


Router# 

Router#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
Router (config) hostname acme_dist 

acme_dist (config) #interface serial 5 


acme_dist (config-if)#encapsulation hdic “This is optional, HDLC is default 
acme_dist (config-if)#eleck rate 56000 ===) “Tells the router to send a clock 
acme_dist (config-if)#compress stac = === “__ Enables STAC compression 

acme_dist (config-if)#ip address 192.168.128.9 255.255.255.252 

acme_dist (config-if)#no shut 

acme_dist (config—if) #exit 

acme_dist (config) # 

acme_dist (config) #interface serial 1 

acme_dist (config-if)#clock rate 1000000 

acme_dist (config-if)#ip address 192.168.128.5 255.255.255.252 

acme_dist (config-if)#no shut 

acme_dist (config-—if) #exit 

acme_dist (config) # 


acme_dist (config) #router eigrp 2001 == ==? This is optional, configures 
acte_dist (config-router) fnetwork 192.168.128.0 - ” EIGRP as the routing protocol 
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acme_dist (config-router) #*Z 
acme_dist# 


Moving on to the credit card center, you must also configure this router for HDLC. The router needs 
compression configured so that it can understand payload compression. To make this lab practical, 
you also need to add an IP address, a routing protocol, and a host name. Example 3-13 illustrates 


the configuration of the credit card center, the cc_center router. 


Example 3-13 HDLC Configuration on the DTE Side of the Network 


Router#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
Router (config) hostname cc_center 

cc_center (config) #interface serial 0 

cc_center(config-if) #encapsulation hdlc 
cc_center(config-if)#compress stac 
cc_center(config-if)#ip address 192.168.128.10 255.255.255.252 
cc_center(config-if)#no shut 
cc_center (config—if) #exit 
cc_center (config) # 
cc_center (config) #router eigrp 2001 
cc_center(config-router) #network 192.168.128.0 
cc_center(config-router) #*Z 

cc_center# 


Finally, Example 3-14 shows the configuration for the Wisconsin branch. This example takes 
advantage of the Cisco defaults and the Cisco convention that allows for minimal unique parsing of 
the command. For example, co can be either configure or copy, but 'cop' is unique, so cop is 
sufficient. Example 3-14 demonstrates these time-saving steps. 


Example 3-14 HDLC Configuration of wi_ branch, Using Defaults and 
Shortened Keystrokes 


Router#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
Router (config) #hostname wi_branch 

wi_branch (config) #int sO 

wi_branch(config-if)#ip add 192.168.128.6 255.255.255.252 
wi_branch(config-if) #no shut 

wi_branch (config—if) # 

wi_branch (config—if) # 

wi_branch(config-if) #router eigrp 2001 

wi_branch (config-router) #network 192.168.128.0 
wi_branch(config-router) #*Z 

wi_branch# 


Reviewing the configurations in their entirety, you have the following listings in Example 3-15. 


Example 3-15 Configuration Listings for Lab 9, ACME Finance 


Distribution Router (acme_dist) 


hostname acme_dist 
! 
<<<text omitted>>> 
! 
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interface Seriall 

ip address 192.168.128.5 255.255.255.252 
clockrate 1000000 

! 

<<<text omitted>>> 

! 

interface Serial5 

ip address 192.168.128.9 255.255.255.252 
clockrate 56000 

compress stac 

! 

<<<text omitted>>> 

! 

router eigrp 2001 

network 192.169.128.0 


Credit Card Center (cc_center) 


hostname cc_center 
! 
interface Serial0O 
ip address 192.168.128.10 255.255.255.252 
no ip directed-broadcast 
no ip mroute-cache 
no fair-—queue 
compress stac 
! 
<<<text omitted>>> 
! 
router eigrp 2001 
network 192.168.128.0 


Wisconsin Branch (wi_branch) 


hostname wi_branch 

! 

<<<text omitted>>> 

! 

interface Serial0 

ip address 192.168.128.6 255.255.255.252 
no ip mroute-cache 

no fair-—queue 

! 

<<<text omitted>>> 

! 

router eigrp 2001 
network 192.168.128.0 


To verify this particular configuration, a couple of commands are useful: show interface serial x, 
show ip eigrp neighbors, and, of course, ping. When the lab is fully functional you see two EIGRP 
neighbors on the acme_dist router, one to each of the other routers. The show interface 
commands show the line up, the protocol up, and DCD, DSR, DTR, RTS, and CTS all in an up state. 
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Chapter 4. WAN Protocols and Technologies: Point-to- 
Point Protocol (PPP) 


Along with the explosion of the Internet came the explosion of the Internet's access protocol, 
the Point-to-Point Protocol (PPP). Most analog dialup connections today run PPP as their data- 
link protocol. This is primarily because of the Internet-friendly capabilities of PPP: 


Error detection 

Network layer address negotiation 
Authentication using CHAP or PAP 
Data compression 

1SO standard 


Before PPP became the dominant Internet access protocol, it was often used—and confused— 
with the Serial Line Internet Protocol (SLIP). Many people commonly referred to point-to- 
point connections using SLIP/PPP. Unfortunately, SLIP supported only IP as its only network 
layer protocol and thereby fell short of the requirements needed for many network 
administrators running IP, |PX, and AppleTalk protocols. 


Cisco's implementation of PPP is modeled after RFC 1661. This RFC explains how PPP is used 
for encapsulating network layer protocol information over point-to-point links. PPP breaks 
down the data link layer into three sublayers. Each sublayer has a specific function: 


e Network Control Protocol (NCP)— Establishes and negotiates network layer 
protocols and addresses. 


e Link Control Protocol (LCP)— Establishes, authenticates, and optionally tests the 
link for quality. 


e High-Level Data Link Control (HDLC)— Encapsulates datagrams over the link. RFC 
1662 describes this procedure. 


Table 4-1 outlines PPP and its sublayers. 


Table 4-1. PPP Sublayers of the OSI Mode 


OSI Layer Common Protocols 
Layer 3 Network layer protocols, such as IP, IPX, and AppleTalk 
Layer 2 Network Control Protocol (NCP) 


Link Control Protocol (LCP) 


High-Level Data Link Control (HDLC) 
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Physical layer 


EIA/TIA-232, V.24, V.35, ISDN, and so on 


Other RFCs significant to PPP are listed here: 


e RFC 1144— TCP/IP header compression. 


e RFC 1220— Point-to-Point Protocol extensions for bridging. This RFC replaces RFC 
1220. 


e RFC 1334— PPP authentication protocols. 


e RFC 1378— PPP AppleTalk Control Protocol (ATCP). 


e RFC 1552— PPP Internetworking Packet Exchange Control Protocol (IPXCP). 


e RFC 1570— PPP LCP extensions. 


e RFC 1661— Point-to-Point Protocol (PPP). 


e RFC 1662— PPP in HDLC-like framing. 


e REC 1990— PPP Multilink Protocol (MP). 


NOTE 


You can find all the RFCs online at www.isi.edu/in-notes/rfcxxxx.txt, where xxxx 
is the number of the RFC. 


As referenced, PPP uses the HDLC protocol as a means by encapsulating datagrams over 
links. The frame structure and principles of PPP are outlined in the International Organization 
for Standardization (1SO) HDLC procedures 3309, amended by 1984/PDAD1 to allow use in 
asynchronous environments and the start/stop transmission. 


Many of PPP's extended capabilities, such as error correction and multiple network layer 
protocols, are controlled by its Link Control Protocol (LCP) and the Network Control Protocols 
(NCP). The LCP frame is sent to configure and optionally test the data link. LCP operates in 
the following manner: 


Step 1. Link establishment phase— LCP first opens the connection and then 
negotiates communications parameters. These include the maximum receive unit, 
compression type, and link authentication protocol type. After link configuration is 
complete, a configuration-acknowledgment frame must be sent and received. This 
step is followed by an optional link-quality determination phase. Here, LCP determines 
whether the link quality is sufficient to bring up network layer protocols. 
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Step 2. "Not so optional" authentication phase— After the link is established and 
the authentication protocol is decided on, the peer goes through the authentication 
specified. Cisco offers the Challenge Handshake Authentication Protocol (CHAP) and 
the Password Authentication Protocol (PAP) for PPP authentication. The PPP standard 
does not require any authentication to take place; this is true for nondial connections 
and ISDN connections. For analog dial configurations running over asynchronous 
links, however, before a Cisco router can bind a route after Step 3, it requires a lower- 
level caller 1D authentication or CHAP and PAP to take place. This might account for 
why PPP configs can work in one location and not in another. To protect yourself 
against this, the Cisco TAC recommends to always use CHAP authentication. RFC 1994 
defines PPP CHAP, which obsoletes RFC 1334. 


Step 3. Network layer protocol phase— At this point, LCP directs NCP to bring up 
the configured network layer protocols. After this phase is complete, packets from 
each network layer protocol can be sent over the link. 


Step 4. Link termination phase— LCP can terminate the link upon user intervention 
or a physical event. LCP directs the NCP to close the Layer 3 protocols and take 
appropriate action. 


LCP accomplishes these phases with three types of LCP frames: 


Link establishment frames— Establishes the link 
Link termination frames— Closes the link 


Link maintenance frames— Used to manage and debug the link 
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The Many Uses of PPP 


PPP is a versatile protocol, and you can configure it on a number of different interface types: 


Synchronous 

Asynchronous 

ISDN 

High-Speed Serial Interface (HSSI) 
Digital subscriber line (DSL) 


As you can already see, PPP can be deployed in a variety of situations. And, as mentioned previously, 
most people use PPP as their data link layer protocol to access the Internet. PPP is also commonly 
used as the data-link layer for Integrated Services Digital Network (ISDN) and when configuring a 
point-to-point link to a non-Cisco device. Another use of PPP can be on a Serial backup link, or to 
"bundle" multiple Basic Rate Interfaces (BRIs) together to maximize bandwidth and load share, such 
as in a PPP multilink scenario. 


When modeling PPP in the internetwork, you will deploy PPP in a number a ways. First, you look at 
configuring PPP on serial links. Then, the chapter expands and applies the same theory to 
asynchronous ports using modems. Finally, the chapter discusses how to implement some of the 
more advanced features of PPP, including PPP compression, PPP multilink, and other PPP features. 
PPP over ISDN is covered in Chapter 7, "WAN Protocols and Technologies: Integrated Services Digital 


Network (ISDN)." 
Configuring PPP on Synchronous Serial Links 


To configure PPP on a Serial interface, you must first enable PPP encapsulation on the interface with 
the encapsulation ppp command. If you are configuring both ends of the PPP link, you need to 
configure PPP encapsulation on each side. If you are configuring a PPP link with two routers, using 
DTE-to-DCE cable connections, you also need to use the clock rate bps command on the DCE side of 
the connection. Essentially, setting the encapsulation coupled with a network layer address is all that 
is needed for a basic PPP configuration. As you will see, this is just the basic configuration, and you 
will be using the more advanced features of PPP in the upcoming sections. 


The first example involves configuring PPP on a serial interface between two Cisco routers. Use Figure 


4-1 as the network diagram and address map, and begin by defining PPP encapsulation on Serial 1 


(S1) of rl and Serial 0 (SO) of r2. Because this is a V.35 back- to-back connection, one side needs to 
be configured as DCE. Use the clock rate statement on the Serial 1 interface of rl to accomplish this. 


Figure 4-1. PPP Network Diagram and IP Scheme 


S0-DTE — 
U sv» —_____— i ——7 a | 
S0-IP-172.16.128.2/30 


$1-IP-172.16.128.1/30 


E0-IP-172.16.1.1/24 | E0-IP-172.16.2.1/24 | 


Example 4-1 demonstrates the configuration commands used for a simple PPP back-to-back 
configuration. 303 


Example 4-1 PPP on a Serial I nterface 


rl(config) #interface sl 


rl(config-if)#elock rate 56000 === © Needed for DCE connection 
(config-if)#ip address 172.16.128.1 255.255.255.252 

rl(config-if)#no shut 

(config-if) #*2Z 


Example 4-2 lists the relevant portions of the configurations for routers rl and r2. 


Example 4-2 Configuration Listings for PPP Back-to-Back Network on rl1 and 
r2 


hostname rl 

! 

interface Ethernet0O 
ip address 172.16.1.1 255.255.255.0 

no ip directed—-broadcast 

! 

interface Seriall 

ip address 172.16.128.1 255.255.255.252 
no ip directed—-broadcast 

encapsulation ppp 
clockrate 56000 

! 

router ospf 2001 
network 172.16.1.1 
network 172.16.128. 


FO 


hostname r2 

! 

interface Ethernet0 

ip address 172.16.2.1 255.255.255.0 
! 

interface Serial0O 

ip address 172.16.128.2 255.255.255.252 
encapsulation ppp 

! 

router ospf 2001 

redistribute connected subnets 
network 172.16.128.2 0.0.0.0 area 1 
default-metric 100 


Configuring PPP on Asynchronous Ports for Analog Dial Links 


Configuring PPP on asynchronous interfaces for analog dial connections can be more involved than 
configuring PPP on serial links. This section briefly lists the steps needed to configure PPP and then 
goes into greater detail on the more complex steps. The steps to configure PPP for use on an 
asynchronous dialup connection are as follows: 


Step 1. Configure the modem and asynchronous port. Step 1 involves attaching and 
configuring the modem, and configuring the asynchronous port of the router. This step also 
includes identifying the absolute line number that corresponds to that asynchronous interface. 
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See Chapter 1, "The Key Components for Modeling an Internetwork," for more information on 
connecting and configuring modems. 


Step 2. Define and configure PPP on the asynchronous interface. Configure the asynchronous 
interface that corresponds to the absolute line number found in Step 1. Configure PPP 
encapsulation and PPP authentication for the asynchronous interface. 


Step 3. Configure network layer addresses or addressing schemas and routing as they 
corresponds to the asynchronous interface. 


Step 4. Configure the asynchronous interface for dial-on-demand routing (DDR). 
Step 1: Modem and Asynchronous Port Configuration 


Carefully follow the outlined instructions in Chapter 1 to properly connect a modem to either the AUX 
port or an asynchronous port on a router. This includes using the modem inout command and the 
modem autoconfigure command or deploying the use of chat scripts. A chat script is always 
needed for the remote router to dial into the host. To call the chat script on dial-out use only, use the 
script dialer script_name command under the absolute line entry. The chat script should be kept 
simple and clean. For example, the following chat script will reset the modem, load the factory 
defaults, and then dial the number 5496561 and wait for a connect message. 


chat-script dialhost "" "ATZ&F" OK "ATDT5496561" TIMEOUT 60 CONNECT 


The chat script is where you actually place the number to be called with analog dial communications. 
The dialer map string also has a telephone number on it, but this is used for authentication and caller 
identification, not for actually placing the call. When the dialer map is deployed in an ISDN 
configuration, the dialer map string is used to place the call. 


Be sure to perform the show line command and make note of the absolute line number that 
corresponds to the port to which the modem was attached. Example 4-3 attaches a modem to the 


AUX port of a Cisco 2500 router. 


Example 4-3 show line Command Listing the Absolute Line Number of the 
AUX Port 


Router#show line 


Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int 
= SOveTY. - 7 - 7 - 0 0 0/0 = 
1 AUx 9600/9600 = = = = = 0 =F ux port 
2 VTY 7 - - 7 - 0 0 0/0 = 
3. VT¥ = - - - - 0 0 0/0 = 
4 VTY - - - - 7 0 0 0/0 = 
> VIY¥ = - 7 7 - 0 0 0/0 = 
6 VTY = - - 7 - 0 0 0/0 = 
Router# 


You later use the absolute line number (1, in this case) to configure an asynchronous link. The 
absolute line number can and will change with different router types, so it is important to perform the 
show line command to verify the absolute line number. For example, Example 4-4 attaches a 
modem to port 16 of the terminal server, and the AUX port is on line 17, not line 1. This example also 
shows the line as being inactive and shows that a transmit and receive clock is also set. This indicates 
that a modem is already configured and attached to the line. 


Example 4-4 show line Command Listing the Absolute Line Number of the 


AUX Port 
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access_server#show line 


Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int 
xO Cry - 7 - = - 7 0 0/0 = 
«de TTY. 9600/9600 - = = = = i. 0 0/0 = 
a 2. TY 9600/9600 - = = = = i. 1776 0/0 = 
* 2 TTY 9600/9600 - = = = = 1 1 0/0 = 
* 4 TTY 9600/9600 - = = = = Hl 0 0/0 = 
x SD. TITY 9600/9600 - = = = - 1 al 0/0 = 
* 6 TTY 9600/9600 - = = = = 1 0 0/0 = 
* OP TTY 9600/9600 - = = = = 1 0 0/0 = 

8 TTY 9600/9600 - = = = = 0 0 0/0 = 
9g TTY 9600/9600 - = = = = 0 0 0/0 = 
10) TIyX 9600/9600 - = = = = 0 0 0/0 = 
Li. TTY 9600/9600 - = = = = 0 0 0/0 = 
12. TITY 9600/9600 - = = = = 0 0 0/0 = 
13. TTY 9600/9600 - = = = = 0 0 0/0 = 
14 TTY 9600/9600 - = = = = 0 0 0/0 = 
LS: TTY. 9600/9600 - = = = = 0 0 0/0 = 
17 AUX 9600/9600 — = = = = 0 0 0/0 = 
18 VTY - = 2 = = af 0 0/0 = 
Lo VIX - - - - 7 0 0 0/0 = 
2.0). VIY 7 7 - - = 0 0 0/0 = 
21 VTY - - - 7 7 0 0 0/0 = 
Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Nig eye 
22 VTY = - - - 7 0 0 0/0 = 


access_server# 
Step 2: Defining and Configuring PPP on the Asynchronous Interface 


Next, configure the asynchronous interface of the router and enable it for PPP. To define the 
asynchronous interface, simply enter the command interface async interface-number. To enable 
PPP on the interface, you must first decide how you want to use PPP and DDR. This is mainly because 
when PPP originated, it was designed to use PPP strings on call establishment. An example of this is 
the / routing command that can be sent upon PPP establishment, to enable routing protocols to 
transverse the link. To accommodate this type of flexible session establishment, Cisco offers a variety 
of commands: 


e async mode {dedicated | interactive}— This command is off by default—that is, no 
asynchronous mode is configured. The line will not be capable of accepting inbound 
networking because PPP and SLIP connections are not enabled. To use any PPP or SLIP 
protocols, you must use one of the two async modes: 


- async mode dedicated means that the router does not wait for any end-user 
prompts. No end-user commands are required to initiate remote connections, and the 
interface is automatically configured for SLIP or PPP. The remote end will not be 
capable of selecting any encapsulation methods, addresses, and other modes. 


- async mode interactive means that the router will accept an EXEC command from 
the end user before a connection is initiated. The async mode interactive command 
should be used if the remote end desires any session-establishment parameters and if 
you want to route over the link. 

e async {dynamic | default} routing— When using the async mode interactive command, 
you must use the async dynamic routing command as well. The async dynamic routing 
command enables the router to accept the / routing keyword when sent by the remote user. 
If the host interface is set in interactive mode, the async default routing command causes 
the ppp and slip EXEC commands to be interpreted as if the / route keyword was included in 
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the command. The async default routing command enables routing protocols on dedicated 
asynchronous interfaces. 


e autoselect {ppp | slip | during-login | arap}— This command is used on the absolute line 
number, where the modem commands are applied. The autoselect command enables the 
router to start a protocol when the appropriate starting character is received. For example, if 
the router receives a return character, it starts an EXEC session. Table 4-2 lists the frame 


flags in hex for SLIP, PPP, and ARAP. 


Table 4-2. PPP Frame Flags 


| Protocol Hexadecimal Frame Flag 
Return character OD 
SLIP Co 


PPP 7E 


[ARAP 10 


e The during-login argument is used when end users or clients of different protocol types 
might be dialing into the same port on the router. For example, this option might be used 
when the client runs a TTY session with a terminal emulator, such as Hyperterm, while at the 
same time another client might want to connect to the same port using PPP. 

e transport input {all | lat | map| nasi | none | pad | rlogin | telnet | v120}— By 
default, Cisco routers do not accept incoming network connections to asynchronous ports. You 
must specify an incoming transport protocol or use the transport input all command before 
the line accepts an incoming connection. 


To enable PPP on an asynchronous port, use the following commands: 


e encapsulation ppp— As stated previously, this command configures the interface for PPP 
encapsulation. 


e ppp authentication {chap | pap}— PPP authentication is required on analog dial lines to 
provide secure and reliable dial connections. 


Challenge Handshake Authentication Protocol and Password Authentication Protocol 


CHAP and PAP authentication are available on all interfaces running PPP. Both protocols were 
originally outlined in RFC 1334, and later CHAP was updated in RFC 1994. CHAP and PAP use the 
concept of each device or router identifying itself with a unique name. The identification process also 
prevents one router from placing a call to another if the other router port is already connected to the 
site for which it is configured. PPP operates in the following manner: 


Step 1. When a PPP session is established, the router determines the type of authentication 
required from LCP. 


Step 2. The router determines the authentication, either CHAP or PAP, and performs one of 
the following: 


- Checks the local database for the proper username and password pairing. This is the 
default setting, and no login local is needed. 


- Forwards an authentication request on to a TACACS+ or RADIUS server. 
Step 3. The router runs its authentication process based on the response that it received from 


the local database or the security server. If the response is positive, the router starts the PPP 
process; if it is negative, the router rejects the user immediately. 


The CHAP and PAP process starts when LCP negotiates the parameters of the link. The PAP process 
sends a clear-text password across the link, which is interpreted by the routers at the remote ends of 
the link. A data scope or line monitor can capture the response and then can spoof the same process 
later; therefore, it is a less secure method of authentication. 


The CHAP process never sends a clear-text password across the link, making it inherently more 
secure then PAP. The CHAP process uses a Message Digest 5 (MD5) hash generator to form a 128-bit 
hash during its challenge process. Only the hash and its modifiers are sent out on the link. 


When an initiating router first issues a challenge to a remote router, the initiating router responds 
with four important parts of information: 


A CHAP challenge packet type identifier 

A supplied version of the ID, a sequential number that identifies the challenge 
A random number 

The host name of the router issuing the challenge 


When the remote router receives the response, it performs a reverse lookup on the username and 
retrieves the password associated with it. The 1D, a random number, and the password are fed into 
the MD5 hash generator. The output from this process is called a hash. The MD5-hashed CHAP 
challenge is the number that is sent back across the link. When the hash is sent, it is sent along with 
the CHAP response packet type identifier, the 1D, and the host name of the router. The initiating 
router performs the same process with the values received from the remote router. That is, the 
initiating router looks up the password associated with the host name sent by the remote router. The 
initiating router then feeds this information, along with the 1D and random number, into the MD5 
hash generator. The result of the process is a hash that is equal to the hash value sent by the remote 
router. If any other result is produced, the remote fails authentication and the link is torn down. 


To configure PPP CHAP authentication, perform the following tasks: 


Step 1. Ensure that PPP encapsulation is configured on the appropriate interface. 


Step 2. On the host router, add a username equal to that of the remote router's host name 
that is dialing into your network. On the remote router, add a username equal to that of the 
host router's host name. The passwords that you assign to the two usernames must match 
exactly. Don't forget that all passwords are case-sensitive. 


Step 3. Under the PPP interface, add the following command for CHAP: 


ppp authentication chap 


Figure 4-2 and Example 4-5 demonstrate two routers configured for PPP CHAP authentication over an 
asynchronous interface. Normally, you would enable service password-encryption, and the 
passwords would be encrypted in the router's listing. For readability and educational purposes, 
however, the passwords have been left unencrypted. 


Figure 4-2. PPP CHAP over Asynchronous Dial Configurations 
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Router 1 Router 2 


(host_router) (remote_router) 
AUXs=line 1 AUX=line 1 
§496870 5496560 
A1-IP-172.16.128.1/30 $0-IP-172.16.128.2/30 
E0-IP-172.16.2.1/24 


Example 4-5 CHAP Authentication Configuration for the host_router over an 
Analog Dial Connection 


hostname host_router 
! 
! 
username remote_router password 0 cisco 
ip subnet-zero 
! 
interface Asyncl 
ip address 172.16.128.1 255.255.255.252 
no ip directed—-broadcast 
encapsulation ppp 
dialer in-band 
dialer map ip 172.16.128.2 name remote_router broadcast 5496560 
async mode interactive 
ppp authentication chap 
! 
ip classless 
! 
! 
! 
line con 0 
exec-timeout 0 0 
transport input none 
line aux 0 
autoselect ppp 
login local 
modem InOut 
modem autoconfigure discovery 
transport input all 
speed 38400 
line vty 0 4 
login 
! 
end 


To configure PPP PAP authentication, perform the following tasks: 


Step 1. Ensure that PPP encapsulation is configured on the appropriate interface. 


Step 2. On the host router, add a username equal to that of the remote router's host name 
that is dialing into your network. On the remote router add a username equal to that of the 
host router's host name. The passwords that you assign to the two usernames must match 
exactly. Don't forget that all passwords are case-sensitive. 


Step 3. Under the PPP interface, add the following commands for PAP: 309 


ppp authentication pap 
Ppp pap sent-username local_device_name password password 


NOTE 


Whenever you are running a PPP dial-in client, and during your session establishment, 
you are prompted for a password, which is a clear indication that the host is issuing you 
a PAP challenge. Many times, this is the case with Internet service providers (ISPs). 


Figure 4-3 illustrates the configuration of PPP PAP in the same network as Figure 4-2. 


Figure 4-3. PPP PAP over Asynchronous Dial Configurations 
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Example 4-6 shows the configurations for the host_router and remote_router for the network in 
Figure 4-3. 


Example 4-6 PAP Authentication Configuration for the host_ router and 
remote_ router over an Analog Dial Connection 


hostname host_router 

! 
username remote_router password 0 ciscol 

ip subnet-zero 

chat-script dialremote "" "ATZ&F" OK "ATDT5496561" TIMEOUT 60 CONNECT 
! 

interface Ethernet0O 

ip address 172.16.1.1 255.255.255.0 

no ip directed—-broadcast 

! 

interface Asyncl 

ip address 172.16.128.1 255.255.255.252 

no ip directed—-broadcast 

encapsulation ppp 

dialer in-band 

dialer idle-timeout 305 

dialer map ip 172.16.128.2 name remote_router broadcast 5496560 
dialer-group 1 

async mode interactive 

Ppp authentication pap 

Ppp pap sent-username host_router password ciscol 
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! 
ip classless 
ip route 172.16.2.0 255.255.255.0 172.16.128.2 
! 
dialer-list 1 protocol ip permit 

! 

! 

line con 0 

exec-timeout 0 0 

transport input none 

line aux 0 

autoselect ppp 

script dialer dialremote 

modem Inout 

modem autoconfigure type usr_sportster 
transport input all 

speed 38400 

line vty 0 4 

login 

! 

end 


host_router# 


hostname remote_router 
! 
username host_router password 0 ciscol 
chat-script dialhost "" "ATZ&F" OK "ATDT5496870" TIMEOUT 60 CONNECT 
! 
interface Ethernet0O 
ip address 172.16.2.1 255.255.255.0 
! 
interface Asyncl 
ip address 172.16.128.2 255.255.255.252 
encapsulation ppp 
async mode interactive 
dialer in-band 
dialer idle-timeout 305 
dialer map ip 172.16.128.1 name host_router broadcast 5496870 
dialer-group 1 
ppp authentication pap 
Ppp pap sent-username remote_router password ciscol 
! 
no ip classless 
ip route 172.16.1.0 255.255.255.0 172.16.128.1 
! 
dialer-list 1 protocol ip permit 
! 
line con 0 
line aux 0 
autoselect ppp 
script dialer dialhost 
modem InOut 
modem autoconfigure discovery 
transport input all 
rxspeed 38400 
txspeed 38400 
line vty 0 4 
login 
! 
end 
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remote_router# 


NOTE 


When assigning host names to routers, it's best to use all lowercase names. If you need 
more text in the name, you can always use the underscore (_) character. Try to stay 
consistent in naming conventions throughout the internetwork or model, to avoid 
possible typos and case-sensitive mismatches. Most often, these occur on map 
statements or an authentication process of one sort. For example, "Host_router" doesn't 
equal "host_router" or "host-router," even though they are all called "host router." This 
might seem confusing at times because some of the router names used are proper 
nouns and are lowercase throughout the book. 


Figure 4-4 is a network diagram and |P address map of an asynchronous PPP dial connection between 
two routers. To configure this model, begin by attaching and configuring a modem to the AUX port of 
each router. You might want to reference Chapter 1 for more detailed information on modem 
configuration. 


Figure 4-4, PPP Network Diagram and IP Scheme for an Asynchronous 
Analog Dial Connection 
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Example 4-7 shows the configuration for the host_router and remote_router in Figure 4-4. 


Example 4-7 PAP Authentication Configuration for host_router and 
remote_ router over an Analog Dial Connection 


hostname host_router 

! 
username remote_router password 0 ciscol 
ip subnet-—zero 

chat-script dialremote "" "ATZ&F" OK "ATDT5496561" TIMEOUT 60 CONNECT 
! 

interface Ethernet0O 

ip address 172.16.1.1 255.255.255.0 

no ip directed—-broadcast 

! 

interface Asyncl 

ip address 172.16.128.1 255.255.255.252 
no ip directed—-broadcast 

encapsulation ppp 

dialer in-band 
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dialer idle-timeout 305 

dialer map ip 172.16.128.2 name remote_router broadcast 5496560 
dialer-group 1 

async mode interactive 

ppp authentication pap 

Ppp pap sent-username host_router password cisco 
! 
ip classless 
ip route 172.16.2.0 255.255.255.0 172.16.128.2 
! 
dialer-list 1 protocol ip permit 

! 

! 

line con 0 

exec-timeout 0 0 

transport input none 

line aux 0 

autoselect ppp 

script dialer dialremote 

modem InOut 

modem autoconfigure type usr_sportster 
transport input all 

speed 38400 

line vty 0 4 

login 

! 

end 


host_router# 


hostname remote_router 
! 


username host_router password 0 ciscol 


chat-script dialhost "" "ATZ&F" OK "ATDT5496870" TIMEOUT 60 CONNECT 


! 
interface Ethernet0O 

ip address 172.16.2.1 255.255.255.0 

! 
interface Asyncl 

ip address 172.16.128.2 255.255.255.252 
encapsulation ppp 

async mode interactive 

dialer in-band 

dialer idle-timeout 305 

dialer map ip 172.16.128.1 name host_router broadcast 5496870 
dialer-group 1 

ppp authentication pap 

Ppp pap sent-username remote_router password cisco 
! 
no ip classless 

ip route 172.16.1.0 255.255.255.0 172.16.128.1 

! 
dialer-list 1 protocol ip permit 

! 

line con 0 

line aux 0 

autoselect ppp 

script dialer dialhost 

modem InOut 

modem autoconfigure discovery 

transport input all 

rxspeed 38400 
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txspeed 38400 
line vty 0 4 
login 

! 
end 


remote_router# 


Example 4-8 demonstrates the configuration of an asynchronous port and the corresponding AUX 


port of a router for dial-in and dial-out PPP connections. This example also includes the configuration 
of the modem. To configure the AUX port for a modem, first perform the show line command and 
find the absolute line number to which the modem will be physically attached. Then, configure that 
port for modem use. Second, configure the asynchronous interface for PPP. 


Example 4-8 Configuration of an Asynchronous Port for a Modem and PPP 
(Steps 1 and 2 Only) 


remote_router#show line 


Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Ine 
we 9Q CTY = = = = = 0 a 0/0 = 
1 BUX 9600/9600 = = = = = 0 = Modem port 
2 VTY = - - = = 0 0 0/0 = 
3 VTY - = = = = 0 0 0/0 = 
4 VTY 7 - - = = 0 0 0/0 = 
> VIY - 7 - - 7 0 0 0/0 = 
6 VTY = = = = = 0 0 0/0 = 


remote_router# 

remote_router#conft t 

Enter configuration commands, one per line. End with CNTL/Z. 
remote_router (config) #interface async 1 
remote_router(config-if) #async mode interactive 
remote_router (config-if) #encapsulation ppp 

remote_router (config-if) #exit 

remote_router (config) # 

remote_router (config) #line 1 

remote_router (config-line) #modem inout 


remote_router (config-line) #transport input all 
remote_router (config-line) #*Z 
remote_router 


( 
( 
( 
( 
( 
( 
remote_router(config-line) #modem autoconfigure discovery 
remote_router (config-line) #autoselect ppp 

( ) 

( ) 

# 


Recall from Chapter 1 that you can add a loopback interface to assist in performing a reverse Telnet 
session to test the modem. Another way to try a quick test is to simply Telnet to the Ethernet 
interface address with a port of 2001. Example 4-9 exhibits a successful reverse Telnet to the modem 
on port 1. When in session with the modem, performing a quick ATZ or a more detailed AT command 
such as AT&V displays the current modem configuration. Be sure that you do not forget to 
disconnect your modem session after testing it using the disconnect command. To do this, complete 
the Ctrl-Shift-6 keyboard function, which brings you back to the router. Then, enter the disconnect 
command. 


Example 4-9 Performing a Reverse Telnet Session to the Modem 


remote_router#telnet 172.16.2.1 2001 
Trying L72216.251, 2001. .2. Open 
atz 
OK 
314 


até&v 

ACTIVE PROFILE: 

Bl El L1 M1 N1 QO T V1 WO XO YO &C1 &D2 &GO &J0 &K3 &0Q5 &R1 &SO &T5 &XO &YO 
S$00:001 S01:000 S02:043 S03:013 S04:010 S05:008 S06:002 S07:055 S08:002 S09:006 
S107014 S115095 ‘S12:050 SlS8:000 S25s005 S26:001 S362007 S372000 S382020 S462138 
S48:007 S95:000 

OK 

CTRL/SHIFT/6 


remote_router#disconnect 
Closing connection to 172.16.2.1 [confirmly 


The last two configuration phases involve configuring network layer addresses and configuring DDR. 
These steps are tightly related to one another because DDR naturally requires some form of a 
network layer addressing to be in place. 


Step 3: Configuring Network Layer Addresses or Addressing Schemas, and Routing as It 
Corresponds to the Asynchronous Interface 


The next step involved in configuring PPP over asynchronous interfaces is to configure all network 
layer addresses for the interfaces. Along with configuring standard addressing, protocol-specific 
issues, such as OSPF, demand circuits should also be configured at this time. 


You can configure IP addressing on the dialer interface in multiple ways. You can configure the router 
to assign an IP address to the client, or the router could assign multiple addresses from a pool or 
could simply ignore the addressing requirements of the client and reference only how to get to the 
address with a dialer map statement. The async dynamic address and peer default ip address 
pool commands are used to assign an IP address to the client from a pool or from the host router. 
Table 4-3 lists the combinations that should be used when configuring and assigning IP addresses to 
a dialer interface. 


Table 4-3. Recommend Router Address and Addressing for PPP 


Host Router Interface Commands Remote Router or Client PPP 
Settings 


Router static | P: Router static | P: 
ip address local_ip_address ip address remote_ip_address 
dialer map ip remote_ip_address dialer map ip local_ip_address 


Router static | P: Router dynamic IP: 
IP address local_ip_address ip address negotiated 
Dialer map ip remote_ip_address dialer map ip a.b.c.d 


Router static IP Windows 95/98/2000 static | P: 


IP address local_ip_address Specify IP address: 
dialer map ip remote_ip_address 
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Router static IP dynamic client: Windows 95/98/2000 dynamic IP: 


ip address local_ip_address IP address obtained automatically: 


peer default ip address remote_ip_address 
remote_ip address 


Router static |P dynamic client from a Windows 95/98/2000 dynamic IP: 
pool: 

IP address obtained automatically 
async dynamic address 
ip address local_ip_address 
peer default ip address pool pool_name 


From the global interface, enter the pool: 


ip local pool {default | pool_name low_ip_ 
address [high_ip_address] } 


Use the ip address negotiated statement when you don't have control of the assignment of the IP 
address on the dialer interface. This might be the case with ISPs. Usually, the ISP will assign you an 
address when you make a PPP connection. Using the ip address negotiated statement enables LCP 
to properly receive an IP address from the host router. You will use this command for "Easy IP 
configuration," which is essentially NAT using a dynamic address as its outside address, with TCP 
overload. 


NOTE 


The command peer default ip address local_ip address must be entered before the 
dialer in-band command is entered. If the dialer in-band is entered first, the router 
will not accept a specific remote peer IP address. 


Figure 4-5 illustrates a Windows 95/98 client dialing into an access server. The Windows workstation 
has its PPP stack configured to receive the IP address automatically. Windows 95/98 dialup 
networking uses PPP PAP for authentication. 


Figure 4-5. Windows 95 PPP Dial-In 
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If the workstation wants access to the Internet, a DNS server needs to be configured on the client if 
DHCP is not used. In Example 4-10, the access server assigns the address of 172.16.20.2 to the PPP 
client dialing in. Notice that the access server also has a dialer list on it. This defines interesting 
traffic so that the link does not terminate while the client is sending data. The dialer idle-timeout 
terminates the line after 5 minutes and 5 seconds (305 seconds) of inactivity. 


Example 4-10 WIN 95 PPP Configuration for an Analog Dial Connection 


hostname access_server 
! 
username userl password 0 ciscol 
ip subnet-zero 
! 
interface Ethernet0O 
ip address 206.191.241.42 255.255.255.248 
no ip directed—-broadcast 
! 
interface Asyncl16 
ip address 172.16.20.1 255.255.255.0 
no ip directed—-broadcast 
encapsulation ppp 
dialer in-band 
dialer idle-timeout 305 
dialer-group 1 
async mode interactive 
peer default ip address 172.16.20.2 
no cdp enable 
ppp authentication pap 
! 
ip classless 
! 
Giateretistitrprotocol ip remmir 
! 
line con 0 
exec-timeout 0 0 
transport input none 
line 1 8 
transport input all 
line 9 15 
line 16 
autoselect ppp 
login local 
modem InOut 
modem autoconfigure type usr_sportster 
transport input all 
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speed 115200 
line aux 0 
line vty 0 4 

login 

! 
end 


access_server# 


NOTE 


By default, the Cisco Discovery Protocol (CDP) is enabled on all interfaces. To disable 
CDP on an interface, use the no cdp enable command. CDP is used in ODR routing and 
to help identify other adjacent Cisco devices. CDP messages can keep dialer lines up if it 
is not disabled on these type of interfaces. CDP can be considered a security risk if it is 
enabled and you are not using ODR. 


Controlling Routing Updates 


The second half of Step 3 involves configuring routing for the DDR link. Proper control of routing 
updates can be one of the most difficult parts of DDR configuration. To prevent routing updates from 
constantly bringing up the link and dialing, you must have thorough knowledge of the routing 
protocol in use. You must also understand how the routing protocol sends and receives updates from 
one network to another, so as not to filter pertinent information. The dilemma for network engineers 
is how to propagate routing information without needing to constantly keep the link active. 


There are several ways to address how to route on a DDR link without keeping the link active all the 
time. To accommodate spoofing and routing updates for distance vector protocols for IP, as well as 
IPX RIP and AppleTalk RTMP, Cisco invented snapshot routing. Snapshot routing involves taking a 
"snapshot" of the routing table and then spoofing the interface that participates in snapshot routing 
of its routing updates for a certain period. This time, called the snapshot quiet time, eventually 
expires, forcing the router to make a call to the snapshot server to receive a routing update. 
Snapshot helped solve some problems of routing over a dynamic link, but it does have a limitation: It 
doesn't support protocols that support variable-length subnet masking (VLSM). To address dynamic 
links for OSPF networks, OSPF uses a concept called demand circuits. 


Demand circuits are complex and are covered in more detail in Chapter 7 covers snapshot routing 
and the dialer watch commands in greater detail. 


As you can see, when modeling or designing any network with dynamic links, it is important to look 
at the routing schema of the entire network. You must consider whether you need to advertise 
networks with different bit boundaries over your backup link. As you will learn in upcoming chapters, 
protocols such as RIP and IGRP accept and advertise only those networks on the same major bit 
boundary whose subnet masks match those of the interface sending or receiving the routing update. 


Table 4-4 lists some suggested methods of routing over dynamic links based on routing schemas that 
Cisco supports. 


Table 4-4. Dynamic and Static Routing Methods over Dial Links Based on 
Routing Protocol Type 


| Routing Protocol | Dynamic Routing Updates Method | Static Method 
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Floating static routes 


AD distance > 170 


ee watch 
wm Snapshot routing 
— 


PX RIP/SAP RIP/SAP PX RIP/SAP |S napshot routing Floating static routes 
IPX ElGRP Snapshot routing Floating static routes 
AppleTalk Snapshot routing Floating static routes 
A common approach to the routing dilemma, and the approach that this section addresses, is the 
application of floating static routes or weighted routes. A floating static route is a static route defined 
as a route that is not permanently entered into the routing table. The route appears only under a 
special set of circumstances. A floating static route is configured as a static route to a destination 
network with an administrative distance greater than the routing protocols in use. This allows the 
route to be advertised through the routing protocol first. If the route learned by the routing protocol 


is lost, the floating static route will be entered into the routing table. The syntax for configuring a 
weighted or floating static route is as follows: 


Floating static routes 


dialer watch AD distance > 100 


OSPF demand circuit Floating static routes 


dialer watch AD distance > 110 


Snapshot routing Floating static routes 


AD distance > 120 


ip route remote_ip_subnet subnet_mask {[ip_next_hop administrative_distance 
(1-255)] interface} 


An administrative distance of 150 to 180 is usually sufficient for weight. Table 4-5 lists the 
administrative distances for routing protocols and static routes. If no administrative distance is added 
to the ip route command, the default distance is 1. If you point the static route to an interface 
instead of the next-hop address, the administrative distance will be 0, as in a connected route. A 
static route that can reach the next-hop IP address will be placed in the forwarding table. A 
connected route will always be in the forwarding table, unless the interface is in a down state. 


Table 4-5. Default Administrative Distances on Cisco Routers 


Route Source/ Type Default Administrative Distance 
somes interface 0 
Static route pointing to an interface 0 
Static route to a next-hop interface 1 
ae summary route 5 
External BGP 20 


El GRP 90 
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External ElGRP 


Internal BGP 
Unknown route 


Unreachable 


Figure 4-6 illustrates the relevant commands needed for using floating static routes to back up a 
serial connection. In this example, you also need to be sure to use the IP subnet-zero command 
because the address 192.168.1.1/30 is being used on the asynchronous link. The natural network for 
the asynchronous link as assigned is 192.168.1.0/30, which is the zero subnet on a Class C network. 
Keeping the DDR link on a separate subnet eliminates the worry of the routing protocol (EIGRP, in 
this case) bleeding routing updates onto the link. This is yet another way to control routing updates 
on a link. 


Figure 4-6. Floating Static Route Configuration for Analog Dial Connection 
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Step 4: Configuring the Asynchronous Interface for Dial-on-Demand Routing 
Dial-on-demand routing (DDR) can be divided into two subgroups: 


e Legacy DDR— Enables a temporary connection only when there is interesting traffic to send 
to that destination. Legacy DDR is configured when a static relationship exists between the 
physical dialing interface and the destination. 


e Advanced DDR with dialer profiles— Used when multiple logical connections want to share 
the same physical interface. This form of DDR exists when one or more logical interfaces 
share the same physical interface on a per-call basis. An example of this is when one router 
wants to dial two different remote locations and run separate Layer 3 protocols. At times, the 
router might want to dial the Internet and run only IP, while at other times, the router might 
want to dial into a headquarters site while running IP and | PX. 
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This section covers legacy DDR; advanced DDR topics are covered in Chapter 7. 


All DDR, whether legacy or advanced, operates in a similar way: 


Step 1. When a router receives traffic, it performs a lookup in the routing table to see 
whether a route exists to the traffic's destination. If a destination exists, an outbound 
interface is associated with it. If this interface is configured for DDR, the router performs 
another lookup to determine whether the traffic is interesting. 


Step 2. The router then locates the next-hop address and uses either the dialing instructions 
in the dialer string command or the dialer map command for ISDN TAs. For modems that 
support V.25bis dialing, the dial number is taken off the chat-script command. V.25bis is an 
ITU-T standard for in-band signaling to bit synchronous DCE devices. 


Step 3. The router checks to see whether the associated interface is in an up state and is 
connected to the remote destination. If the interface is connected, the traffic is sent and the 
dialer idle timer is reset if the traffic is interesting. If the interface is not connected, the router 
sends call setup information to the DCE device on the interface based on the dialer string, 
dialer map, or chat-script arguments. 


Step 4. While the link is connected, the router sends interesting and uninteresting traffic to 
the destination. When the router finishes sending interesting traffic, it sets an idle timer. 
When the idle timer expires, as defined by the dialer idle-timeout command, the router 
disconnects the call. 


Configuring DDR is a four-step process: 


Step 1. Define interesting traffic— Defining interesting traffic can be done in one of two 
ways. The whole protocol suite might be defined as interesting, or an access list can be called 
to further narrow down significant traffic by type or destination. The syntax needed to define 
DDR is as follows: 


dialer-list dialer-group_number protocol protocol_name [permit | 
deny | list access-—list_number] 


Step 2. Enable DDR and assign a dialer list to an interface— To enable DDR on an 
interface, use the dialer in-band command for V.25bis devices, and use the dialer-group 
command on the interface. The dialer in-band command specifies for the interface that will 
be used to perform call setup and teardown between the router and an external dialing 
device. ISDN devices use the D channel for call setup and teardown, so the dialer in-band 
command is not needed for ISDN BRIs and PRIs. The dialer-group command assigns the 
interface to the dialer list, which, in turn, defines which traffic is interesting. The dialer- 
group must match the dialer list number. The commands to accomplish this are as follows: 


- dialer in-band 


- dialer-group 1-10 
Step 3. Define destination parameters— This step involves configuring a next-hop address 
and determining how the router will reach that address. It also involves what name the router 
will use for authentication and how the router will treat the DDR connection. This is also a 
good time to define a dialer idle-timeout. To configure a next-hop addresses and determine 
how the router will reach the next hop, use either the dialer map or the dialer string 
commands. The dialer string command can be used with the dialer remote-name 
command for CHAP authentication. 


The dialer map statement is the first cousin of the frame-relay map statement. The dialer 
map statement tells the router how to reach the next-hop address by protocol type. The 
current protocols supported are AppleTalk, bridging, |SO CLNS, DECnet, HPR, IP, |1PX, LLC2, 
NetBIOS, snapshot routing protocol, Banyan VINES, and XNS. 304 


dialer map protocol_name next_hop_address [name remote_device_name] 
[class class_name] [speed 56 | 64] [broadcast] [dialer_string] 


The name parameter should always equal the host name of the remote router connected to 
the interface. This parameter is used for authentication purposes. 


A class can be added, as you will see in PPP callback. The speed and dialer_string arguments 
are used for ISDN interfaces only. The speed is set at a default of 64 kbps. The dialer_string 
is for ISDN, where the string is the telephone number that the router will dial when interesting 
packets to the next-hop address are received. For asynchronous devices, such as modems, 
you must use a chat script for the router to pass the dial string onto e device. Finally, DDR is 
nonbroadcast by default; however, if broadcast traffic is to cross the link, the broadcast 
keyword must also be added. 


The dialer map command enables you to express a lot of DDR commands on one line. Some 
of these commands can be entered individually: 


- dialer string dialer_string 
- dialer remote-name remote_device_name 


- dialer idle-timeout seconds 
The dialer idle-timeout is the idle timer that is set to mark when the last interesting traffic 
was sent. If no further interesting traffic is sent before the idle timer expires, the link is 
disconnected. The default idle dialer is 120 seconds. 


Step 4. Configure optional call parameters— Additional call parameters can be added to 
the interface at this time. Some of the more useful ones are as follows: 


dialer fast-idle seconds— This command is primarily used with multiple dialer 
profiles, such as in a DDR with dialer profiles configuration. When two logical dial 
interfaces are competing for the same physical line, the timer specifies how long the 
line can remain idle before the current call is disconnected and another dialer interface 
can place a call. This command should be used when contention for a link is 
particularly high. You will see this command used in the Chapter 7. 


dialer load-threshold 1-255 [outbound | inbound | either]— This command 
specifies the interface load at which the dialer initiates another call to the destination. 
The value is set at a load between 1 and 255, as in the show interface command; 1 
is the lowest load, which makes the dialer call almost immediately. This can be 
tweaked further by specifying the direction of the traffic. This command is used in 
conjunction with the ppp multilink command, as discussed in an upcoming section. 


Using an earlier example of PPP PAP authentication, you can now focus on the DDR portion of the 
configuration. Figure 4-7 illustrates two routers connected through modems attached to their AUX 


ports. When each router detects traffic destined toward the subnet defined in the static routes, it 
dials the other router. This call stays connected until no IP traffic has crossed the subnet for 305 
seconds. This time limit is assigned in the dialer idle-timeout statements. 


Figure 4-7. Network Topology for the PPP Analog Dial Configuration 
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Example 4-11 shows the configurations for the host_router and remote_router in Figure 4-7. 


Example 4-11 PPP Analog Dial Configuration 


hostname host_router 
! 
username remote_router password 0 ciscol 
ip subnet-zero 
chat-script dialremote "" "ATZ&F" OK "ATDT5496561" TIMEOUT 60 CONNECT 
! 
interface Ethernet0O 
ip address 172.16.1.1 255.255.255.0 
no ip directed—-broadcast 
! 
interface Asyncl 
ip address 172.16.128.1 255.255.255.252 
no ip directed—-broadcast 
encapsulation ppp 
dialer in-band 
dialer idle-timeout 305 
dialer map ip 172.16.128.2 name remote_router broadcast 5496560 
dialer-group 1 
async mode interactive 
ppp authentication chap 
! 
ip classless 
ip route 172.16.2.0 255.255.255.0 172.16.128.2 
! 
dialer-list 1 protocol ip permit 
! 
! 
line con 0 
exec-timeout 0 0 
transport input none 
line aux 0 
autoselect ppp 
script dialer dialremote 
modem InOut 
modem autoconfigure type usr_sportster 
transport input all 
speed 38400 
line vty 0 4 
login 
! 
end 


host_router# 
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hostname remote_router 

! 

username host_router password 0 ciscol 
chat-script dialhost "" "ATZ&F" OK "ATDT5496870" TIMEOUT 60 CONNECT 
! 

interface Ethernet0O 

ip address 172.16.2.1 255.255.255.0 

! 

interface Asyncl 

ip address 172.16.128.2 255.255.255.252 
encapsulation ppp 

async mode interactive 

dialer in-band 

dialer idle-timeout 305 

dialer map ip 172.16.128.1 name host_router broadcast 5496870 
dialer-group 1 

ppp authentication chap 

! 
no ip classless 

ip route 172.16.1.0 255.255.255.0 172.16.128.1 
! 
dialer-list 1 protocol ip permit 

! 

line con 0 

line aux 0 

autoselect ppp 

script dialer dialhost 

modem InOut 

modem autoconfigure discovery 

transport input all 

rxspeed 38400 

txspeed 38400 
line vty 0 4 

login 

! 
end 


remote_router# 


To reiterate, recall the step-by-step list for configuring PPP over asynchronous interfaces. This step- 
by-step list is a useful tool in configuring PPP over asynchronous interfaces: 


Step 1. Modem and asynchronous port configuration: Step 1 involves attaching and 
configuring the modem, and configuring the asynchronous port of the router. This step also 
includes identifying the absolute line number that corresponds to that asynchronous interface. 
See Chapter 1 for more information on connecting and configuring modems. 


Step 2. Define and configure PPP on the asynchronous interface. Configure the asynchronous 
interface that corresponds to the absolute line number found in Step 1. Configure PPP 
encapsulation and PPP authentication for the asynchronous interface. 


Step 3. Configure network layer addresses or addressing schemas, and routing as it 
corresponds to the asynchronous interface. 


Step 4. Configure the asynchronous interface for dial-on-demand routing (DDR). 
Configuring PPP Compression 


PPP also offers the use of data payload compression to maximize performance across low-bandwidth 
links. Compression is negotiated by LCP during link initialization. Because LCP negotiates thigo4 


parameter, it is necessary to have compression configured on both sides of the link. Cisco offers 
three types of payload compression on PPP links, along with standard TCP header compression: 


e Predictor— Predictor compression is accomplished through a "lossless" predictor algorithm 
that learns data patterns and can predict the next character in the data stream. The algorithm 
is called "lossless" because the scheme reproduces the original bit stream exactly, with no 
degradation or loss. Predictor is more memory-intensive and less CPU-intensive. 


e Stacker— Stacker, as mentioned in Chapter 3, "WAN Protocols and Technologies: High-Level 
Data Link Control (HDLC)," is a Lempel-Ziv (LZ)-based compression algorithm. This algorithm 
tries to predict the next sequence of characters in the data stream by using an index to look 
up a sequence in compression dictionary. The route sends each data type once with 
information about where the type occurs within the data stream. Stacker is more CPU- 
intensive and less memory-intensive than Predictor. 


e MPPC— Outlined in RFC 2118, Microsoft Point-to-Point Compression (MPPC) allows Cisco 
routers to exchange data with Microsoft clients. MPPC uses LZ-based compression. Like 
Stacker, MPPC is more CPU-intensive and less memory-intensive than Predictor. 


The preceding compression techniques are configured with the compress command at the interface 
level. To enable payload compression, use the following interface command: 


compress [predictor | stac | mppc | 


When enabling compression, the link should always be restarted or cleared with the clear interface 
interface_name command. This forces the routers or LCP to renegotiate the link with compression 
enabled. You cannot use any form of payload compression with TCP header compression. 


TCP header compression, as defined in RFC 1144, uses the Van Jacobson algorithm for compressing 
TCP headers. TCP header compression is most useful when deployed in an environment where there 
are many small data packets. TCP header compression can significantly cut down on the TCP 
overhead associated with these packets. To enable TCP header compression, use the following 
interface command: 


ip tcp header-compression [passive] 


The passive argument compresses outbound TCP packets only if incoming TCP packets on the same 
interface are compressed. If the passive argument is not specified, all traffic is compressed. 


Compression is most effective if the data that you are transferring is highly compressible, such as a 
text file or ASCIl-based data. Files such as JPEG or MPEG files are already compressed to a great 
extent, and compression merely slows down the router and the transfer of this type of data. 
Compression will also increase the number of CPU cycles and the amount of memory used by the 
router. Therefore, you should apply careful consideration to current memory and processor usage 
before enabling compression. 


Two useful commands for analyzing whether compression is in use, are the show processes and 
show processes buffers commands. Example 4-12 lists the output of the show processes 


command. Here we see the average utilization of this router is approximately 30 percent. In this 
case, the router has enough resources to enable compression. Be careful when implementing 
compression on routers operating at 65 percent of capacity. 


Example 4-12 Output from the show processes Command 


skynet_2#show processes 
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Cisco offers hardware accelerator cards, or compression service adapters (CSAs), to 
offset the overhead compression that uses valuable router resources. Cisco compression 
is performed on the CSA boards if present in the router. 


Configuring PPP Multilink 


PPP multilink is a mechanism for combining, or bundling, multiple physical links into one large logical 
link. The logical end-to-end connection is called a bundle. This bundle provides increased bandwidth 

to the destination, along with reduced latency by allowing packets to be disassembled and sent down 
different links simultaneously to the same destination. 


The most common use of PPP multilink is with ISDN, which can use PPP multilink to bind two 64-kbps 
B channels together to form a single 128-kbps link. ISDN is the most common use of PPP multilink; 
however, it is also supported on the following interfaces: 


Figure 4-8 illustrates how a PPP multilink is formed. 


Asynchronous interfaces 
Synchronous interfaces 


ISDN interfaces 


- ISDN BRI 


- ISDN PRI 


Figure 4-8. PPP Multilink Bundles 
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When a bundle is formed, it can be formed with different physical interface types. For example, an 
asynchronous interface can be joined with a synchronous interface to form a bundle. 


NOTE 


PPP multilink is outlined in RFC 1990, which replaces RFC 1717. RFC 1990 specifies 
multivendor interoperability and resolves some earlier ISDN sequencing issues. 


PPP multilink is an option negotiated by LCP during its initial negotiation period. After negotiation, PPP 
multilink operates by first splitting packets into fragments. The fragments then are sent at the same 
time over multiple point-to-point links to the same remote address. When the fragments arrive at the 
other side of the connection, LCP reassembles them into a packet. 


To configure PPP multilink, use the following commands on the interface or dialer on which you want 
to configure PPP multilink: 


ppp multilink 
dialer load-threshold load [inbound | outbound | either] 


The dialer load-threshold command specifies the interface load at which the dialer initiates another 
call to the destination. The value is set at a load between 1 and 255, as in the show interface 
command; 1 is the lowest load, which makes the dialer call almost immediately. This can be tweaked 
further by specifying the direction of the traffic. 


NOTE 


Cisco |1OS Software Release 11.1 is the first release to support PPP multilink. Cisco |OS 
Software Release 11.3 includes a feature called the Bandwidth Allocation Control 
Protocol (BACP). BACP enables two routers to negotiate which peer will add or remove 
links during a session. 


To verify the functionality of PPP multilink, use the debug ppp negotiation script along with a 

source ping. By turning on the debug for PPP, you can tell when LCP brings up another channel or 

link. By performing a extended ping, you can easily force a large amount of data quickly across the 

link to exceed the load threshold and bring up another PPP bundle. The show ppp multilink 

command can also be useful to show the state of a multilink session. Example 4-13 demonstrates the 
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use of the show ppp multilink command, followed by an extended ping, which brings up the 
second multilink bundle. 


Example 4-13 show ppp multilink Command Output 


skynet_2#show ppp multilink 


Virtual-Accessl1, bundle name is cns_isdn_callback 
Dialer interface is Dialerl 
0 lost fragments, 0 reordered, 0 unassigned, sequence 0x0/0x0 rcevd/sent 
0 discarded, 0 lost received, 1/255 load 
Member links: 1 (max not set, min not set) 


BRIO:1 = “ony one active bundle 
skynet_2#ping 
Protocol. [ap]: ip 
Target IP address: 172.16.16.2 
Repeat count [5]: 1000 
Datagram size [100]: 2000 
Timeout in seconds [2]: 5 
Extended commands [n]: 
Sweep range of sizes [n]: 


Type escape sequence to abort. 


Sending 1000, 2000-byte ICMP Echos to 172.16.16.2, timeout is 5 seconds: 
[FI Da ST A A iE PF YC DR UF LS Fe 


Success rate is 100 percent (370/370), round-trip min/avg/max = 152/161/284 ms 
skynet_2#show ppp multilink 


Virtual-Accessl, bundle name is cns_isdn_callback 
Dialer interface is Dialerl 
0 lost fragments, 0 reordered, 0 unassigned, sequence 0x496/0x2F1 rcevd/sent 
0 discarded, 0 lost received, 25/255 load 
Member links: 2 (max not set, min not set) 
SS CBOSIERISyate eugene bundle 
BRI0:2 
skynet_2# 


Configuring PPP LAPB and LQM 


PPP link quality can be enforced or enabled on Cisco routers in two ways. One method is done by 
enabling LAPB numbered mode negotiation. This is done with the ppp reliable-link command. 
Another method is by enforcing Link Quality Monitoring (LQM) on the link with the ppp quality 
command. 


LQM monitors the link quality; if the quality drops below a configured percentage, the router shuts 
down the link. The percentages are calculated for both incoming and outgoing traffic. The LQM out is 
calculated by comparing the total number of packets and bytes sent with the total number of packets 
and bytes received by the destination node. The incoming LQM is measured by comparing the total 
number of packets and bytes received with the total number of packets and bytes sent by the 
destination peer. 


When LQM is enabled, Link Quality Reports (LQRs) are sent in place of keepalives. LQR is further 
defined in RFC 1989, "PPP Link Quality Monitoring." 
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NOTE 


LAPB numbered mode inserts essentially another error-correction layer with retransmits, 
if necessary, while LQM monitors link quality. 


To enable LQM, use the following command: 


ppp quality percentage_of_successful_traffic 


The other form of increasing link reliability is to use the ppp reliable-link command. This command 
causes the router to provide LAPB numbered mode negotiation. LAPB performed on the data-link 
layer can provide error detection for many upper-layer protocols, such as PPP, in this case. 


You must enable PPP reliable link on both ends of the link. Unlike ppp quality, you can use the ppp 
reliable-link command with compression; however, you cannot use PPP reliable link with PPP 
multilink. To verify that these commands are functioning, use debug ppp negotiation because 
LQM will be listed there. 


The "Big show" and "Big D" for PPP and DDR 


Cisco offers some strong commands for debugging PPP and DDR sessions. Again, this section focuses 
on the best and most useful show and debug commands. The "big show" and "Big D" for PPP and 
DDR are as follows: 


e show interface interface_name— The show interface command provides useful information 
about the physical state of the interface. The interface will always show UP and spoofing mode 
when configured for DDR. 


e show line x— The show line command provides useful information on the physical state 
and, to some degree, the logical state of the interface. For more information on the show 
line command, see Chapter 1. 


e show ip route— Use the show ip route command to verify that the PPP subnet is up and 
active. The subnet shows "connected" only when the link is actually up and connected on both 
ends. 


e debug ppp negotiation— This command is probably the most useful command for 
debugging PPP sessions. Every aspect of LCP negotiation is listed in the output. Example 4-14 
demonstrates a PPP session being negotiated between two routers. Look for IPCP to finish in 
an open state for IP protocols. You will see a CP negotiate for every PPP option and protocol 
specified. 


e debug ppp authentication— This command instantly points out any PPP authentication 
errors, such as CHAP and PAP errors. See Example 4-15 for a demonstration of PPP 
authentication failure. 


e debug dialer— debug dialer commands are used primarily to debug when dialing occurs. As 
the debug dialer command shows, successful dialing occurs only when DDR and ACLs have 
been configured correctly. 


The following examples show some of the "big Show" and the "big D" commands in action. The 

debugs should all be used together because they present a clearer picture of what is happening. In 

Example 4-14, all the debugs from the preceding list, along with debug async state, have been 
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turned on. 


Example 4-14 Output of a Successful debug ppp negotiation 


01:01:57: Asyncl: Dialing cause ip (s=172.16.128.2, d=172.16.1.1) ‘Dial is 
01:01:57: Asyncl: Attempting to dial 5496561 

01:01:57: CHAT1: Attempting async line dialer script 

01:01:57: CHAT1: Dialing using Modem script: dialhost & System script: none 
01:01:57: TTY1: cleanup pending. Delaying DTR 

01:01:57: CHAT1: process started 

Ol 0175 7¢ CHATIs Asserting DIR 

OL O12St2 TIYLs Sét. DIR to: 1 

O1201+57: CHATI: Chat: script dialhost started... ia. 


‘~ Modem connected 
01:02:14: TTY1: destroy timer type 1 
01:02:14: TTY1: destroy timer type 0 
‘~ Ppp started 

01:02:14: Asl AAA/ACCT: Using PPP accounting list "" 
01:02:14: Asl IPCP: Install route to 172.16.128.1 
01:02:16: SLINK-3-UPDOWN: Interface Asyncl, changed state to up 
01:02:16: Asl PPP: Treating connection as a callout 

‘~ PEP negotiation begins 
01:02:16: Asl LCP: O CONFREQ [Closed] id 21 len 20 
OLs02+ 16s Asl. LEP: ACCM 0x000A0000 (0x0206000A0000) 
O1lsO2¢162 Asli CPs MagicNumber 0x0069B38A (0x05060069B38A) 
01202516: Asl LCP: PFC (0x0702) 
01<s02:16: Asl LCP: ACFC (0x0802) 


01:02:18: Asl LCP: TIMEFout: State REQsent 
01:02:18: Asl LCP: O CONFREQ [REQsent] id 22 len 20 


01:02:18: Asl LCP: ACCM 0x000A0000 (0x0206000A0000) 
01:02:18: Asl LCP: MagicNumber 0x0069B38A (0x05060069B38A) 
01:02:18: Asli LCP: PFC (0x0702) 

O1202+182 Ast LCP: ACFC (0x0802) 


01:02:20: Asl LCP: TIMEFout: State REQsent 
01:02:20: Asl LCP: O CONFREQ [REQsent] id 23 len 20 


O12 02:20¢ Asi LCP: ACCM 0x000A0000 (0x0206000A0000) 
01:02:20: Asl LCP: MagicNumber 0x0069B38A (0x05060069B38A) 
01:02:20: Asl LCP: PFC (0x0702) 

01:02:20: Asl LCP: ACFC (0x0802) 

01:02:20: Asl LCP: I CONFACK [REQsent] id 23 len 20 

012022205 Ag LCP: ACCM 0x000A0000 (0x0206000A0000) 
01¢02:20: Asl LCP: MagicNumber 0x0069B38A (0x05060069B38A) 
01:02:20: Asl LCP: PFC (Qx0702) 

01:02:20: Asl LCP: ACFC (0x0802) 

01:02:20: Asl LCP: I CONFREQ [ACKrcevd] id 180 len 25 
01:02:20: Asl LCP: ACCM 0x000A0000 (0x0206000A0000) 
01:02:20: Asli LCP: AuthProto CHAP (0x0305C22305) 

01:02:20: Asl LCP: MagicNumber 0x0A548C93 (0x05060A548C93) 
01:02:20: Asli LCP: PFC (0x0702) 

01:02:20: Asl LCP: ACFC (0x0802) 

01:02:20: Asl LCP: O CONFACK [ACKrcevd] id 180 len 25 
O1ls023205 Asi. HEP: ACCM 0x000A0000 (0x0206000A0000) 
01:02:20: Asl LCP: AuthProto CHAP (0x0305C22305) 

01:02:20: Asl LCP: MagicNumber 0x0A548C93 (0x05060A548C93) 
01:02:20: Asl LCP: PFC (0x0702) 

01:02:20: Asl LCP: ACFC (0x0802) 

BEAU Se DEC reece eee apes 
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01:02:20: Asl PPP: Phase is AUTHENTICATING, by the peer “CHAP begins 
‘— cHaP challenge 


01:02:20: Asl CHAP: O RESPONSE id 39 len 34 from “remote_router" 


‘~ cHAP OK 
01:02:20: Asl PPP: Phase is UP 
‘~ rp Parameters 
01:02:20: Asl IPCP: Address 172.16.128.2 (0x0306AC108002) 
01:02:20: Asl CDPCP: O CONFREQ [Closed] id 9 len 4 
01:02:20: Asl IPCP: I CONFREQ [REQsent] id 22 len 10 
O1*02220¢ Asli TPCPs Address 172.16.128.1 (0x0306AC108001) 
01:02:20: Asl IPCP: O CONFACK [REQsent] id 22 len 10 
01:02:20: Asl IPCP: Address 172.16.128.1 (0x0306AC108001) 
01:02:20: Asl CDPCP: I CONFREQ [REQsent] id 22 len 4 
01:02:20: Asl CDPCP: O CONFACK [REQsent] id 22 len 4 
01:02:20: Asl IPCP: I CONFACK [ACKsent] id 9 len 10 
O1LS02220: Asli IPCP: Address 172.16.128.2 (0x0306AC108002) 
— 


01:02:20: dialer Protocol up for Asl 

01:02:20: Asl CDPCP: I CONFACK [ACKsent] id 9 len 4 

01:02:20: Asl CDPCP: State is Open 

01:02:21: SLINEPROTO-5-UPDOWN: Line protocol on Interface Asyncl, changed state to 
up 

remote_router# 


Example 4-15 illustrates a PPP CHAP failure on a link with the debug ppp authentication command. 


Example 4-15 PPP CHAP Failure 


skynet_lab#debug ppp authentication 

Se0 PPP: Phase is AUTHENTICATING, by the peer 

SeO CHAP: I CHALLENGE id 51 len 31 from "skynet_lab" 

Se0Q CHAP: O RESPONSE id 51 len 31 from "isp_router" 

SeOQ CHAP: I FAILURE id 51 len 25 msg is "MD/DES compare failed" 
Se0 PPP: Phase is AUTHENTICATING, by the peer 

SeO CHAP: I CHALLENGE id 52 len 31 from "skynet_lab" 

Se0 CHAP: O RESPONSE id 52 len 31 from "isp_router" 


The debug ppp negotiation command can be one of the most powerful debugs available for PPP. 
It's not too data-intensive, and it provides enough information to solve or narrow down a majority of 
PPP-related problems. 


NOTE 
Technique, Technique, Technique 


It might seem that some of these examples and labs are overcomplicated with routing 
protocols and by using VLSM, but there is a reason for this. Too often, many texts and 
examples use standard 24-bit address space and pay little attention to addressing and 
other techniques. This just puts the engineer into bad habits of IP address design. In 
most of this text, IP addresses are assigned just like they would be in the field. Constant 
reinforcement in examples like this improves your technique. Much in the same way that 
a martial artist pays strict attention to the smallest detail of every move, you must pay 
strict attention to every command that you make. If you don't know the purpose of a 
command in a configuration, ask yourself, "Is it a necessary command?" 
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Configuring PPP Callback 


PPP callback is a way for a remote or calling router to place a call to a callback server, terminate the 
link, and then receive a call from the callback server. This method can be used to enhance security 
and to control which side of the link gets connection time. Configuring PPP callback is covered in 
detail in Chapter 7. 
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Lab 10: Configuring PPP, PAP, and Compression over Asynchronous 
Dialup—Part | 


Practical Scenario 


This chapter began describing PPP as the dominant Internet access protocol. PPP is not only used 
to access the Internet, but it also is widely used by many telecommuters and for remote access to 
private corporate networks. Many corporate applications such as Citrix or WIN frame, as well as 
most e-mail servers, require IP as the network layer protocol. To reach these applications, it is 
necessary to run IP on the remote client workstation and use PPP as the data-link protocol. 


Lab Exercise 


The Skynet testing facility is a secret networking test site. New Cisco |OS Software features are 
tested there, and many types of internetwork infrastructures are modeled. At times, engineers 
require secure remote access to Skynet. Currently, only one engineer, code name JP, has access 
to the lab. You have been tasked with configuring a secure remote access connection. Use the 
following guidelines in your design: 


e Windows 95/98/2000 will be the client. The IP address should be set to dynamic. 

e The user ID is JP, and the password is trashman. 

e JP will need to run several Visual Basic programs requiring IP services. This will require IP 
access to the host 172.16.1.10, which is local to the Ethernet segment. 


Lab Objectives 
e Configure the access server and network as depicted in Figure 4-9. 
Figure 4-9. PPP Access to Skynet Testing Facility 


Windows 95/98/2000 client 
skynet_lab with dial-up networking 


= 


(ynemic ji 
102 163 20.090 will bo aenigred 
User lOaJP 
E0-IP-172.16.1.1/24 Pasewordstreshmner 


AB-IP-192.168.1.5/30 


Eiternnet segracat 


EO-IP-172.16.1.10 


e Use PPP on the asynchronous link. 
e Configure the proper authentication protocol for Windows 95/98/2000 client, with the 


username and password specified. 
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e Allow the link to drop after 10 minutes of inactivity. 

e Also allow a TTY session to the access server so it can be used with a standard terminal 
emulator, such as HyperTerm. 

e Optional: Increase performance of the link. 


Equipment Needed 


e One Cisco router, preferably an access server, a Cisco rolled cable, a head-shell labeled 
MODEM, and a modem. 

e One Windows 95/98/2000 workstation with modem. 

e Optional: To model the actual lab as depicted in Figure 4-9, you will also need an Ethernet 
hub, and an additional workstation. However, this is not an integral part of the lab. 


Physical Layout and Prestaging 


Connect the modem, hub, and workstation to the router, as shown in Figure 4-9. 

e Configure a Windows 95/98/2000 dialup networking session. Set the workstation to obtain 
its IP address automatically. For authentication, use the user ID of JP and the password of 
trashman. Remember, this is case-sensitive. 
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Lab 10: Configuring PPP, PAP, and Compression over Asynchronous 
Dialup—Part Il 


Lab Walkthrough 


Attach the modem to the access server or auxiliary port with the Cisco rolled cable. Use the Cisco 
head-shell labeled Modem to attach the modem to the cable. In the lab, use line or port 8 of the 
access server. 


To configure skynet_lab, the access server, you need to perform your four-step process for 
configuring PPP over asynchronous links. Applying a slight modification to the steps so that they fit 
this specific lab, you have the following sequence: 


Step 1. Perform initial setup of the access server. This includes using a host name of 
skynet_lab, setting an enable password, and configuring the Ethernet interface as shown. 
To facilitate additional testing from the remote client, you might want to configure the 
router for Telnet access and reverse Telnet. 


Step 2. Configure line 8 for modem use and to autoselect the encapsulation type during 
login. 


Step 3. Configure the asynchronous interface for IP and PPP with PAP authentication and 
client address negotiation. This includes configuring a username of JP with a password of 
trashman. 


Step 4. Configure the asynchronous interface for DDR. 


Step 5. Optional: Configure MPPC compression. 


First, you need to perform some initial setup on the access server. You set a host name and set an 
enable password: 


Router (config) #hostname skynet_lab 
skynet_lab (config) #enable password cisco 


Next, perform the show line command to verify the absolute line number to which the modem will 
be attached. If Telnet access is to be enabled, also note where the vty line numbers start. Example 


4-16 demonstrates the show line command. Notice that line number for port 8—it is TTY port 8. 
The lines for Telnet sessions start on 18 and run through 22. 


Example 4-16 The show line Command 


skynet_lab#show line 


Tty Typ Tx Rx A Modem Roty AccO AccI Uses Noise Overruns Int 

eo 1OiICLY: - - - - - 0 0 0/0 - 
1. TTY 9600/9600 —- = % % =: 0 0 0/0 = 

a oy en 9600/9600 —- - - - - 0 al 9/27 - 
3 TT 9600/9600 —- = = = - 0 1 0/0 = 
4 TTY 9600/9600 —- - - - - 0 0 0/0 - 
5. TTY 9600/9600 —- = = = = 0 ay 0/0 = 
o TTY 9600/9600 —- = =; ae : 0 0 0/0 S 
i EY 9600/9600 —- - - - - 0 0 0/0 = 

*~ Modem port 

9 TTY 9600/9600 — = = = = 0 0 0/0 = 


130): Sey 9600/9600 - = = = = 0 0 0/0 = 
TA “DEY 9600/9600 - = = = = 0 0 0/0 = 
LZ LT 9600/9600 - = = = = 0 0 0/0 = 
13: PLY 9600/9600 - = = = = 0 0 0/0 = 
14 TTY 9600/9600 - = = = = 0 0 0/0 = 
Lo. LLY 9600/9600 - = = = = 0 0 0/0 = 
16 TTY 9600/9600 - = = = = 0 0 0/0 = 
17 AUX 9600/9600 - = a: a: = 0 0 0/0 - 


| 


skynet_lab# 


Next, you need to configure line 8 for modem and PPP use. You need to use the autoselect 
during-login command to select what type of session starts on the line. If the client dials in with a 
terminal emulator, a TTY session starts. If the client starts a PPP session, a PPP session is 
negotiated. The autoselect ppp command must also be used to start the PPP session. You also 
must configure the modem on line 8. Because you do not know the modem type, the 
autoconfigure type default command is used. Example 4-17 demonstrates the configuration of 


line 8 for modem and PPP use. 


Example 4-17 Configuration of a Line for Modem and PPP Use 


skynet_lab#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
skynet_lab (config) #line 8 

skynet_lab (config-line) #modem inout 
skynet_lab(config-line) #modem autoconfigure type default 
skynet_lab (config-line) #login local 
skynet_lab(config—line) #autoselect during-login 
skynet_lab(config-line) #autoselect ppp 
skynet_lab(config—line) #transport input all 

skynet_lab (config-line) #*Z 

skynet_lab# 


To verify that the modem has been properly configured, use the show line x command—in this 
case, show line 8. Here, you are checking that the modem is configured. You also might want to 
use the debug confmodem command to ensure that the AT string was properly received by the 
mode. Refer back to Chapter 1 for more information on debugging modems, such as using reverse 


Telnet. 


The asynchronous interface should be configured next. The asynchronous interface must match the 
line number that the modem is on—in this case, 8. At this time, you also want to configure the 
asynchronous interface for PPP and PAP authentication. Windows 95/98 clients use PAP 
authentication to authenticate PPP. Example 4-18 shows how to configure PPP encapsulation and 


PAP authentication. 


Example 4-18 Configuring PPP Encapsulation and PAP Authentication 


skynet_lab#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
skynet_lab (config) #int a8 

skynet_lab (config-if) #encapsulation ppp 
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skynet_lab(config-if)#ppp authentication pap 
skynet_lab (config-—if) #exit 

skynet_lab (config) #username JP password trashman 
skynet_lab# 


The next step, demonstrated in Example 4-19, involves setting the IP address of the asynchronous 


interface and using the peer default ip address remote_ip_ address command to assign an |P 
address to the PPP client dialing into the router. 


Example 4-19 Configuring Local and Remote | P Addresses 


skynet_lab (config) #int a8 
skynet_lab(config-if) #ip address 192.168.1.5 255.255.255.252 
skynet_lab(config-if) #peer default ip address 192.168.1.6 


You now can configure the router for DDR. For DDR, you need to add the following the 
configurations under the asynchronous interface: 


dialer in-band 

dialer idle-timeout x 
dialer-groupx 

async mode interactive 


The dialer in-band allows for V.24bis dialing. The dialer idle-timeout and dialer-group 
commands define interesting traffic and determine how long the line can be idle of that traffic 
before disconnecting. Finally, the async mode interactive command allows for incoming 
connections. 


Under the global configuration level, you need to enter a dialer-list 8 protocol ip permit 
command. The dialer list can be simple in this config because the router is not initiating a call or 
routing over the link. Example 4-20 shows the DDR configuration process. 


Example 4-20 Configuring DDR 


skynet_lab (config) #int a8 
skynet_lab(config-if) #dialer in-band 
skynet_lab(config-if) #dialer idle-timeout 600 
skynet_lab(config-if) #dialer-group 8 
skynet_lab(config-if) #asyne mode interactive 
skynet_lab(config-if) #exit 

skynet_lab (config) #dialer-list 8 protocol ip permit 
skynet_lab (config) # 


When this is complete, you can begin to test the configuration. To test the modem, use the debug 
confmodem and debug modem commands, as mentioned in Chapter 1. Example 4-21 lists the 
output of these commands. Here, you can see that the router is properly sending an AT command 
to the modem. 


Example 4-21 Output from debug modem and debug confmodem 
Commands 


skynet_lab#debug modem 
skynet_lab#debug confmodem 
d06h: TTY8: Line reset by "Exec" 
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TY8: Modem: IDLE->HANGUP 

TY8: destroy timer type 0 

TY8: destroy timer type 1 

TY8: destroy timer type 3 

TY8: destroy timer type 4 

TY8: destroy timer type 2 

TY8: dropping DTR, hanging up 
ty8: Modem: HANGUP->IDLE 

TY8: restoring DTR 

TY8: autoconfigure probe started 


t 


t 


t 


t 


2aaaaaaaaaa 
Sooec eae OC OC 6 6:6 
DADAAAAHAAD 
serv Teerees Ss 


a ER SS a eh ea ed. te 


1d06h: TTY8: Detected modem speed 115200 
1d06h: TTY8: Done with modem configuration 


Verifying that the physical layer is working, you can test the network layer. Begin by turning on the 
"Big D" for PPP: debug ppp Negotiation, debug ppp authentication, and debug ppp error. 
Initiate a PPP session to the router by a Windows 95/98/2000 workstation. In this particular lab, 
you are looking for four tasks to complete successfully: 


e PPP initializes— that is, the modem picks up and the fist PPP string is received. 


e LCP finishes PPP negotiation. 
e PAP finishes successfully. 
IPCP installs the proper IP address to the remote end. 


Example 4-22 lists the debug output, showing all four phases completing successfully and 
assigning the proper IP address to the Windows 95/98 client. 


Example 4-22 debug Output from a Successful Dial Connection 


skynet_lab#debug ppp negotiation 

skynet_lab#debug ppp authentication 

skynet_lab#debug ppp error 

1d06h: As8 IPCP: Install route to 192.168.1.6 

1d06h: sLINK-3-UPDOWN: Interface Async8, changed state to up 
1d06h: As8 PPP: Treating connection as a callin 


1d06h: As8 LCP: I CONFREQ [Listen] id 3 len 23 

1d06h: As8 LCP: ACCM 0x000A0000 (0x0206000A0000) 

1d06h: As8 LCP: MagicNumber Ox00F1EF7A (0x050600F1EF7A) 
1d06h: As8 LCP: PFC (0x0702) 

1d06h: As8 LCP: ACFC (0x0802) 

1d06h: As8 LCP: Callback 6 (0x0D0306) 

1d06h: As8 LCP: O CONFREQ [Listen] id 15 len 24 

1d06h: As8 LCP: ACCM 0x000A0000 (0x0206000A0000) 

1d06h: As8 LCP: AuthProto PAP (0x0304C023) 

1d06h: As8 LCP: MagicNumber O0xE7427D86 (0x0506E7427D86) 
1d06h: As8 LCP: PEC ((Ox0702) 

1d06h: As8 LCP: ACFC (0x0802) 

1d06h: As8 LCP: O CONFREJ [Listen] id 3 len 7 

1d06h: As8 LCP: Callback 6 (0x0D0306) 

1d06h: As8 LCP: I CONFREQ [REQsent] id 4 len 20 

1d06h: As8 LCP: ACCM 0x000A0000 (0x0206000A0000) 

1d06h: As8 LCP: MagicNumber Ox00FI1EF7A (0x050600F1EF7A) 
1d06h: As8 LCP: PFC (0x0702) 

1d06h: As8 LCP: ACFC (0x0802) 
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LCP: O CONFACK [REQsent] id 4 len 20 

LCP: ACCM 0x000A0000 (0x0206000A0000) 

LCP: MagicNumber Ox00FI1EF7A (0x050600F1EF7A) 
LCP PFC (0x0702) 

LCP ACFC (0x0802) 

LCP: TIMEout: State ACKsent 

LCP: O CONFREQ [ACKsent] id 16 len 24 

LCP: ACCM 0x000A0000 (0x0206000A0000) 

LCP: AuthProto PAP (0x0304C023) 

LGPs MagicNumber O0xE7427D86 (0x0506E7427D86) 
LCP: PFC (0x0702) 

LCP: ACFC (0x0802) 

LCP: I CONFACK [ACKsent] id 16 len 24 

LCP: ACCM 0x000A0000 (0x0206000A0000) 

LCP: AuthProto PAP (0x0304C023) 

LCP: MagicNumber O0xE7427D86 (0x0506E7427D86) 
LCP: PFC (0x0702) 

LCP: ACFC (0x0802) 


jones a 
‘Pap begins 

PAP: I AUTH-REQ id 1 len 16 from "JP" 
PAP: Authenticating peer JP 
PAP: O AUTH-ACK id 1 len 5 
PPP: Phase is UP = pap completes 
IPCP: O CONFREQ [Closed] id 9 len 10 = pce begins IP setup 
PCP? Address 192.168.1.5 (0x0306C0A80105) 
CDPCP: O CONFREQ [Closed] id 4 len 4 
IPCP: I CONFREQ [REQsent] id 1 len 40 
EPCPR? CompressType VJ 15 slots CompressSlotID (0x0206002D0F01) 
IPCP? Address 0.0.0.0 (0x030600000000) 
IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) 
IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) 
IPCPs SecondaryDNS 0.0.0.0 (0x830600000000) 
IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) 
IPCP: O CONFREJ [REQsent] id 1 len 34 
TPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01) 
IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) 
IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) 
IPCP:? SecondaryDNS 0.0.0.0 (0x830600000000) 
IPCP? SecondaryWINS 0.0.0.0 (0x840600000000) 
CCP: I CONFREQ [Not negotiated] id 1 len 15 
CCP: MS-PPC supported bits 0x00000001 (0x120600000001) 
CCP: Stacker history 1 check mode EXTENDED (0x1105000104) 
LCP: O PROTREJ [Open] id 17 len 21 protocol CCP 


LCP: (0x80FD0101000F12060000000111050001) 

LCP’: (0x04) 

IPCP: I CONFACK [REQsent] id 9 len 10 

DPCRs Address 192.168.1.5 (0x0306C0A80105) 

LCP: I PROTREJ [Open] id 5 len 10 protocol CDPCP (0x820701040004) 


CDPCP: State is Closed 

IPCP: TIMFout: State ACKrcvd 

IPCP: Address 192.168.1.5 (0x0306C0A80105) 
IPCP: I CONFACK [REQsent] id 10 len 10 

IPCP: Address 192.168.1.5 (0x0306C0A80105) 
IPCP: I CONFREQ [ACKrcvd] id 2 len 34 

IPCP: Address 0.0.0.0 (0x030600000000) 
IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) 
IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) 
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1d06h: As8 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) 

1d06h: As8 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) 

1d06h: As8 IPCP: O CONFREJ [ACKrcvd] id 2 len 28 

1d06h: As8 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) 

1d06h: As8 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) 

1d06h: As8 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) 

1d06h: As8 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) 

1d06h: As8 IPCP: I CONFREQ [ACKrcvd] id 3 len 10 

1d06h: As8 IPCP: Address 0.0.0.0 (0x030600000000) 

1d06h: As8 IPCP: O CONFNAK [ACKrcvd] id 3 len 10 

1d06h: As8 IPCP: Address 192.168.1.6 (0x0306C0A80106) 

1d06h: As8 IPCP: I CONFREQ [ACKrcvd] id 4 len 10 

1d06h: As8 IPCP: Address 192.168.1.6 (0x0306C0A80106) 

1d06h: As8 IPCP: O CONFACK [ACKrcvd] id 4 len 10 

1d06h: As8 IPCP: Address 192.168.1.6 (0x0306C0A80106) 
*~ IPcP completes and is Open 


skynet_lab#ping 192.168.1.6 


*~ source PING 
Protocol [ip]: ip 
Target IP address: 192.168.1.6 
Repeat count [5]: 
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: y 
Source address or interface: 172.16.1.1 
Type of service [0]: 
Set DF bit in IP header? [no]: 
Validate reply data? [no]: 
Data pattern [OxABCD]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Sweep range of sizes [n]: 
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 192.168.1.6, timeout is 2 seconds: 


Success rate is 100 percent (5/5), round-trip min/avg/max = 136/166/196 ms 
skynet_lab# 


Most PPP problems become evident with the "Big D" enabled. Without the debugs, it becomes 

difficult to spot analog dialup errors. Make sure that all four phases are completed, followed by 
some source pings from 172.16.1.1 to 192.168.1.6 to verify IP connectivity. Some of the most 
common problems to look for are as follows: 


e PPP not even starting (no ppp debug messages) -— This points to a modem or physical 
problem. Ensure that autoselect PPP is enabled. 


e PPP authentication fails— This message is listed clearly in the debug; to correct it, 
ensure that your passwords match. 


e Route not installed to destination networks— Part of DDR is ensuring that a route 
exists to the proper networks. This also involves checking for the correct |P address to get 
negotiated or sent to the PPP client. 


To increase performance on this link, you can enable MPPC on interface A8 and disable CDP. To 
enable MPPC compression, simply add the compress mppc command on the interface. After 
adding this command to the interface, you can see MPPC get successfully negotiated in Example 4- 


23. To disable CDP on the interface, use the no cdp enable command on the interface. 
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Example 4-23 debug Output for MPPC Compression 


1d07h: As8 CCP: O CONFREQ [Closed] id 2 len 10 


1d07h: As8 CCP: MS-PPC supported bits 0x00000001 (0x120600000001) 
<<<text omitted>>> 
1d07h: As8 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) 


NOTE 


If you use two routers to test the PAP connection instead of a router and workstation, 


you need to use the command ppp pap sent-username under the async interface 


for a successful PAP challenge to occur. 


Finally, Example 4-24 shows the complete configuration for skynet_lab. 


Example 4-24 Complete Listing of skynet_lab 


interface Ethernet0O 
ip address 172.16.1.1 255.255.255.0 
no ip directed-broadcast 


ip address 192.168.1.5 255.255.255.252 
no ip directed-broadcast 
encapsulation ppp 

no ip mroute-cache 

dialer in-band 

dialer idle-timeout 600 

dialer-group 8 

async mode interactive 

peer default ip address 192.168.1.6 
compress mppc 
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no cdp enable 

Ppp authentication pap 
! 
ip classless 

! 
dialer-list 8 protocol ip permit 
! 
line con 0 

exec-timeout 0 0 
transport input none 
line 17 

transport input all 
line 8 

autoselect during-login 
autoselect ppp 

login local 

modem InOut 

modem autoconfigure type default 
transport input all 
speed 115200 

line 9 16 

line aux 0 

line vty 0 4 

login local 

! 

end 


skynet_lab# 
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Lab 11: Configuring PPP, CHAP, and LQM over Synchronous Links— 
Part | 


Practical Scenario 


PPP CHAP provides secure authentication for peer-to-peer networking sessions over many types of 
media. As mentioned earlier, PPP is used over serial, asynchronous, ISDN, and DSL, as well as 
other media types. Today, PPP is even becoming the encapsulation for some LAN- based networks. 
Again, this is mainly because of the peer-to-peer authentication that PPP provides. 


Lab Exercise 


The Skynet testing facility just upgraded its Internet connection to T1. The date of the install 
coincides with the release of a couple of big Internet games. Skynet views this as the perfect time 
to stress test the new link. You have the task to provide a quick and secure connection to the 
Internet. Use the following parameters as your design guidelines: 


e Use PPP as your data-link protocol. The host name of the ISP router is isp_ router. The 
CHAP password is 2diablo2. Use CHAP authentication. 

e At this time, this is Skynet's only link to the Internet and is the only route out of the 
Skynet network. 

e Configure the link so that it will not tolerate a 40 percent packet loss. 


Lab Objectives 
e Configure the access server and network, as depicted in Figure 4-10. 


Figure 4-10. Skynet Testing Facility PPP Serial Connection Access to 
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e Use PPP with CHAP as the data-link protocol on the synchronous link to the ISP. 

Enforce Link Quality Management on the link. 

e Optional: There is a DNS server for the ISP; its address is 128.200.1.2. Configure the 
skynet_lab router to use this DNS server. That is, you should be able to ping www.cisco. 


com when logged on to the skynet_lab router. This might or might not be SS te 


depending on your lab. What is most important is the correct configuration in the router to 
forward DNS requests. 


Equipment Needed 


e Two Cisco routers, connected through V.35 back-to-back cables or in a similar manner 
e Two LAN segments, provided through hubs or switches 
e One optional workstation functioning as a DNS server 


Physical Layout and Prestaging 


e Connect the hubs and serial cables to the routers, as shown in Figure 4-10. 
e Connect two Ethernet hubs to form two LAN segments, as shown in Figure 4-10. 
e Optionally connect and configure a DNS server on the ISP LAN segment. 
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Lab 11: Configuring PPP, CHAP, and LQM over Synchronous Links— 
Part Il 


Lab Walkthrough 


Attach two routers in a back-to-back fashion, using either a V.35 cable or CSU/DSUs with a 
crossover cable, as depicted in Figure 4-10. 


To configure skynet_lab, you can preserve most of your configuration from the previous lab. 
Here, you essentially configure PPP over the interface, enable CHAP, and enforce LQM. 


First, configure the serial interfaces for PPP by changing the encapsulation type to PPP. At this 
time, also set a username for the remote router, isp_router, and set the password to 2diablo2: 


skynet_lab(config) #username ips_router password 2diablo2 
skynet_lab(config) #int sO 

skynet_lab(config—if) #encapsulation ppp 
skynet_lab(config—-if) #ppp authentication chap 


Normally, this would be all that is required for a PPP connection over a serial link; however, you 
still want to enable and enforce LQM and DNS. To enable LQM on the interface to tolerate a loss 
of no more then 40 percent, use the ppp quality percentage_of_successful_ traffic command. 
The PPP quality is measured in a percentage of successful traffic, so you should set this value to 
60. 


Moving over to the ISP router, you configure that router in much the same way that you 
configured the Skynet router. Example 4-25 demonstrates the commands needed on the ISP 


router. 


Example 4-25 Configuration of the I|SP PPP Connection 


isp_router (config) #username skynet_lab password 2diablo2 
isp_router (config) #int sO 

isp_router(config-if) #ip address 196.128.128.6 255.255.255.0 
isp_router(config—if) #encapsulation ppp 
isp_router(config—-if) #ppp authentication chap 
isp_router(config—if) #elock rate 2000000 
isp_router(config—-if) #ppp quality 60 
isp_router(config-if) #*Z 


You can verify the functionality of the serial links by performing a ping of the remote serial 
interface from both routers. If you enable debug ppp negotiation and debug ppp 
authentication, you see LQM messages being exchanged on the link, as well as PPP CHAP 
authentication being performed. 


The last step is to configure the router for both the ISP and Skynet. Skynet will have only one 
route out of the network at this time, so you should use a default route pointing all outbound 
traffic to the ISP's serial interface. Three commands work together to accomplish this: 


e ip classless 
e ip default-network 0.0.0.0 
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e ip route 0.0.0.0 0.0.0.0 196.128.128.6 


The ip classless command tells the router to forward any traffic destined toward a subnet not 
found in its routing table. Without this command, the router will not forward any traffic if the 
router does not have a route to the destination. The ip default-network commands set the 
default route to 0.0.0.0, and the ip route command is a static route pointing to the 0.0.0.0 
catchall network. All traffic will be forwarded to the next-hop address entered here. 


For the ISP, you should be more specific about the routing. Here, you should simply make one 
static route pointing toward the remote network: 


ip route 172.16.1.0 255.255.255.0 196.128.128.5 


After this is complete, ensure that you have two-way connectivity by issuing extended pings, 
sourced from each router's Ethernet port. If you perform show ip route on Skynet, you should 
see the default route set, as demonstrated in Example 4-26. 


Example 4-26 show ip route of Skynet and the IP Router—Note the 
Default Route Set 


skynet_lab#show ip route 
Codes: C — connected, S — static, I - IGRP, R —- RIP, M — mobile, B —- BGP 
D — EIGRP, EX — EIGRP external, O - OSPF, IA —- OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 — IS-IS level-2, * - candidate default 
U -— per-user static route, o — ODR 
T — traffic engineered route 


Gateway of last resort is 196.128.128.6 to network 0.0.0.0 © Default route set 


Cc 201.201.201.0/24 is directly connected, Loopback0O 

196.128.128.0/24 is variably subnetted, 2 subnets, 2 masks 
Cc 196.128.128.4/30 is directly connected, Serial0 
c 196.128.128.6/32 is directly connected, Serial0 

172.16.0.0/24 is subnetted, 1 subnets 
Cc 172.16.1.0 is directly connected, Ethernet0O 

192.168.1.0/30 is subnetted, 1 subnets 
Cc 192.168.1.4 is directly connected, Async8 

“~ IP next hop of default route 


skynet_lab# 


isp_router#show ip route 
Codes: C — connected, S — static, I - IGRP, R —- RIP, M — mobile, B - BGP 
D — EIGRP, EX — EIGRP external, O - OSPF, IA —- OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 — IS-IS level-2, * - candidate default 
U —- per-user static route, o — ODR 


Gateway of last resort is not set 


128.200.0.0/24 is subnetted, 1 subnets 
Cc 128.200.1.0 is directly connected, Ethernet0O 
172.16.0.0/24 is subnetted, 1 subnets 
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196.128.128.0/24 is variably subnetted, 2 subnets, 2 masks 
Cc 196.128.128.5/32 is directly connected, Serial0 
Cc 196.128.128.0/24 is directly connected, Serial0 
isp_router# 


The stage is optional, and it allows the forwarding of DNS requests to a DNS server. To forward 
DNS requests, two commands are needed: 


e ip name-server DNS server_!IP_address 
e ip domain-lookup 


The ip name-server command tells the router the IP address of the DNS server, whereas the ip 
domain-lookup command forwards the UDP DNS packets. Example 4-27 demonstrates the 
configuration and use of the DNS server at the ISP. This example was taken from a real ISP 
router; note that the lab has no "real" connection to the Internet, so these statements are shown 
only for reference and will not be present in Example 4-28. 


Example 4-27 Configuration and Use of DNS Services on a Route 


skynet_lab(config) #ip name-server 204.221.151.248 

skynet_lab (config) #ip domain-—lookup 

skynet_lab (config) #*Z 

skynet_lab#ping www.cisco.com 

Translating "www.cisco.com"...domain server (204.221.151.248) [OK] 


Type escape sequence to abort. 

Sending 5, 100-byte ICMP Echos to 198.133.219.25, timeout is 2 seconds: 
Success rate is 100 percent (5/5), round-trip min/avg/max = 112/114/116 ms 
skynet_lab# 


If you have problems with DNS, ensure that you have IP connectivity to the DNS server, and 
also make sure that the router's UDP packets are being forwarded. 


Example 4-28 shows the router configurations in their entirety. 


Example 4-28 Router Configurations for Skynet and the ISP Route 


skynet_lab#show running-config 
Building configuration... 


Current configuration: 

! 

version 12.0 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
! 

hostname skynet_lab 

! 

enable password cisco 

! 

username JP password 0 trashman 
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username isp_router 0 2diablo2 
ip subnet-—zero 
! 
interface Ethernet0 
ip address: 17261621. 1. 255.255.2550 
no ip directed-broadcast 
! 
interface Serial0d 
ip address: 196.128.128.595. 250.259.2090 <«202 
no ip directed-broadcast 
encapsulation ppp 
no ip mroute-cache 
no fair-queue 


ppp quality 60 
! 


interface Seriall 

no ip address 

no ip directed-broadcast 

shutdown 

! 
interface Async8 

ip address 192.168 .1.5 255.255.259«2592 
no ip directed-broadcast 
encapsulation ppp 

no ip mroute-cache 

dialer in-band 

dialer idle-timeout 600 
dialer-group 8 

async mode interactive 

peer default ip address 192.168.1.6 
compress mppc 

no cdp enable 


ppp authentication pap 
! 


ip classless 

ip default-network 0.0.0.0 
ip route 300.040 0. 00..0. ah 
! 


96.6128 ..128 416 


dialer-list 8 protocol ip permit 
! 

line con 0 

exec-timeout 0 0 

transport input none 

line 17 

transport input all 

line 8 

autoselect during-login 
autoselect ppp 

login local 

modem InOut 

modem autoconfigure type default 
transport input all 

speed 115200 

line 9 16 

line aux 0 

line vty 0 4 

login local 

! 


end 
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skynet_lab# 


isp_router#show running-config 
Building configuration... 


Current configuration: 
! 
version 11.2 
no service password-encryption 
no service udp-small-servers 
no service tcp-small-servers 
! 
hostname isp_router 
! 
‘username skynet_lab password 2diablo2 
! 
interface Ethernet0 
ip address 128.200 21.1 255.255.2550 
! 
interface Serial0d 
ip address 196.128.2128 ..6 255.255.2550 
encapsulation ppp 
clockrate 2000000 


ppp quality 60 
! 


interface Seriall 
no ip address 
shutdown 

! 

interface BRIO 

no ip address 
shutdown 

! 

no ip classless 
io: route 172.1661 .0' 255.255.255.0 196.126.1285 
! 

line con 0 
exec-timeout 0 0 
line aux 0 

line vty 0 4 
login 

! 


end 


isp_router# 
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Lab 12: Configuring PPP Analog Backup for Synchronous Links— 
Part | 


Practical Scenario 


Most sites that have ISDN or analog backup for their serial links use PPP as the data-link protocol. 
A common struggle with DDR is ensuring that it dials only at the appropriate times. An ISDN or 
asynchronous line that is dialing because of an improperly configured ACL can be costly. Other 
limitations put upon the design of your network also might force you to configure dial backup in 
another fashion. For example, if you had to configure a dial interface in OSPF Area O or another 
regular area, it would dial continuously because of link-state flooding. 


Lab Exercise 


The SuperGreat Food Corp. runs an IP-based automated inventory system on an IBM 3090x- 
based platform at its corporate headquarters. Each branch is connected to SuperGreat Foods 
through a 64-kbps PPP connection. Located at each branch is an RS6000. The RS6000 requires | P 
connectivity to the mainframe, as well as the SuperGreat IP network. The SuperGreat IP network 
is in autonomous system 2001; for full 1P reachability, you must run EIGRP on all links. Design 
your network in accordance to the following guidelines set forth form SuperGreat Corp: 


e Use PPP as your data-link protocol on all serial links. Authenticate with CHAP on all PPP 
links. The CHAP password is cub9biggs. 

e Using EIGRP as the routing protocol, you must exchange routes on all links. Use 2001 as 
the autonomous System ID. 

e Configure the serial link so that, upon loss of the circuit, the AUX port will provide dial 
backup. You must send and receive routing updates on the backup port as well. 


Lab Objectives 
e Configure the SuperGreat network, as depicted in Figure 4-11. 


Figure 4-11. SuperGreat Foods PPP Network with Dial Backup 
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e Use PPP on the serial link between the branch and the corporate router. 

e Configure analog dial backup between the two sites so that only a loss of the PPP circuit 
will trigger a call. 

e Use EIGRP as the routing protocol. Do not use any static routes. 


Equipment Needed 


e Two Cisco routers, connected through V.35 back-to-back cables or in a similar manner. 
The LAN type is not significant. 

e Two analog modems, Cisco rolled cables, and MODEM head-shells. 

e Two LAN segments, provided through hubs or switches; the LAN type is not important to 
the configuration of the lab. 

e Two Windows 95/98/2000 workstations with IP configured to simulate the IBM mainframe 


and RS6000, as in Figure 4-11. 
Physical Layout and Prestaging 


e Connect the hubs, serial cables, and modems to the routers, as shown in Figure 4-11. 

e Connect one Token Ring hub to the sub_branch router, and connect the Ethernet hub to 
the sub_corp router. 

e Connect and configure two IP-based workstations for testing purposes. 
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Lab 12: Configuring PPP Analog Backup for Synchronous Links—Part Il 


Lab Walkthrough 


Attach two routers in a back-to-back manner using either V.35 cables or CSU/DSUs with a crossover 
cable, as depicted in Chapter 1 for additional help in configuring and attaching modems to a router's 


AUX port. 


The design requirements call for you to use EIGRP as the routing protocol. The requirements also call 
for you to dial only when the PPP circuit is lost. To force an interface to be in a standby mode and to 
pick up and dial only under a unique circumstance, Cisco offers the backup interface command. 


The backup interface command specifies that an interface stays idle until certain circumstances 
occur: 


e The primary link goes down, resulting in loss of the data link layer. 
e The load on the primary link reaches a certain threshold. 
e The load on the primary link exceeds a specified threshold. 


The backup interface command is used on the serial interface that is your primary interface. If you 
have a 2503 router, two serials, and one ISDN port, and if you were backing up the serial interface 
with the ISDN interface, the serial interface is referred to as the primary interface, and the ISDN is 
called the secondary. The backup interface command would go on the serial interface, called the 
primary interface, not the ISDN interface. The syntax for the backup command is as follows, entered 
in interface mode: 


backup interface interface_name_or_type 


You also can configure a time period specifying how much time should elapse before a secondary link 
status changes after primary link status has changed. There are two way to accomplish this: 


e A delay that applies after the primary link goes down but before the secondary link is 
activated. 

e A delay that applies after the primary link comes up but before the secondary link is 
deactivated. The syntax used to insert a delay is as follows: 


backup delay {enable-delay | never} {disable-delay | never } 


e A backup load also can be specified. This tells the secondary link to activate based on the 
amount of traffic on the primary link. This is done with the following command: 


backup load {enable-threshold | never}{disable-load | never} 


As soon as the backup command is entered on an interface, it immediately forces it into a standby 
state. Example 4-29 shows a link in backup mode.When the interface is in this state, it does not 


respond to pings. 


Example 4-29 Status of Link with the backup Command 


Asyncl is standby mode, line protocol is down 
Hardware is Async Serial 
Internet address is 192.168.128.10/30 
MTU 1500 bytes, BW 38 Kbit, DLY 100000 usec, rely 255/255, load 1/255 
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Encapsulation PPP, loopback not set, keepalive not set 
DTR is pulsed for 5 seconds on reset 

LCP Closed 

Closed: IPCP, CDPCP 


In this circumstance, the backup command will come in handy. When deploying a backup strategy 
with the backup command, you should limit dialing to one side of the network. You might encounter 
scenarios in which multiple sites dial into the same BRI port or analog ports. If the backup command 
is places on both ends of the link, you run the risk of having the host stay in a down standby mode 
on one side of the link. A good example of this could be with Frame Relay, where each side of the link 
is dependent only on the local Frame Relay switch. In a Frame Relay network, it is possible of have 
one end of the link "Line UP, Protocol UP"; the backup command would not activate the secondary 
link, while, at the same time, the end of the Frame Relay network might be down. Therefore, it is 
recommended that you use the backup command only on the remote end of the link. 


With a backup strategy in mind, focus on configuring the branch router first. To configure the branch 
router, you need to perform the following: 


e Perform initial setup of the router. This includes a host name and a username for sug_corp, 
along with a password. 

e Configure the Token Ring interface for IP, and ping RS6000. Use the IP address of 
172.200.1.1/24 for the ToO port of the router. 

e Configure the Serial 0 interface for PPP and IP. Use the IP address of 196.168.128.6/30. 

e Configure EIGRP on the router, use AS 2001, and use the networks 196.168.128.0 and 
172.200.0.0. 


After this is complete, your config should have parts that resemble the ones in Example 4-30. 


Example 4-30 Initial Setup of the sug_ branch 


hostname sug_branch 

! 

enable password cisco 
! 


username sug_corp password 0 cub9biggs = = =) “Used for CHAP 
ip subnet-—zero 
! 
interface Serial0 
ip address 192.168.128.6 255.255.255.252 
no ip directed—-broadcast 
encapsulation ppp 
no ip mroute-cache 
no fair-queue 
ppp authentication chap 
! 
interface Seriall 
no ip address 
no ip directed—-broadcast 
shutdown 
! 
interface TokenRingO 
ip address 172.200.1.1 255.255.255.0 
no ip directed—-broadcast 
ring-speed 16 
! 
router eigrp 2001 
network 192.168.128.0 
network 172.200.0.0 
no auto-summary 
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! 

no ip classless 
! 

line con 0 

line aux 0 

line vty 0 4 
login 

! 

end 


Before concerning yourself with the modem and the dial backup configuration, you should configure 
the host site. Configuring the sug_corp router is similar to configuring the sug_branch router. To 
configure the sug_corp router, perform the following actions: 


e Perform initial setup of the router. This includes the host name and a username for 
sug_branch, along with a password. 

e Configure the Ethernet interface for IP, and ping the mainframe. Use the IP address of 
172.16.1.1/24 for the EO port of the router. 

e Configure the Serial 0 interface for PPP and IP. Use the IP address of 196.168.128.5/30. 

e Configure EIGRP on the router, use AS 2001, and use the networks 196.168.128.0 and 
172.16.0.0. 


After completing this, your configuration should resemble Example 4-31. 


Example 4-31 sug_corp Listing 


hostname sug_corp 
! 


enable password cisco 
! 
username sug_branch password 0 cubSbiggs = “"_ Used for CHAP 
! 
interface Ethernet0O 
ip address 172.16.1.1 255.255.255.0 
! 
interface Serial0 
ip address 192.168.128.5 255.255.255.252 
encapsulation ppp 
no fair-queue 
clockrate 64000 
ppp authentication chap 
! 


interface Seriall 
no ip address 
shutdown 
! 
router eigrp 2001 
network 192.168.128.0 
network 172.16.0.0 
no auto-summary 
! 
no ip classless 
! 
line con 0 
line aux 0 
line vty 0 4 
login 
! 
end 
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At this time, you should have full IP connectivity from the RS6000 to the mainframe. Test for full 
connectivity by issuing pings from RS6000 to the mainframe. Also check the route table on each side 
of the network to ensure that the 172.16.1.0 and 172.200.1.0 networks are being advertised to each 
other. An EIGRP neighbor also should be built over the serial interface. Example 4-32 lists the route 


table on sug_branch followed by the show eigrp neighbors command. 


Example 4-32 Routing Table on sub_ branch and show eigrp neighbor 
Command 


sug_branch#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M —- mobile, B —- BGP 
D — EIGRP, EX — EIGRP external, O -— OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U - per-user static route, o -— ODR 
T - traffic engineered route 


Gateway of last resort is not set 


192.168.128.0/24 is variably subnetted, 3 subnets, 2 masks 


D 192.168.128.8/30 [90/70440192] via 192.168.128.5, 00:09:19, Serial0 
Cc 192.168.128.4/30 is directly connected, Serial0 
Cc 192.168.128.5/32 is directly connected, Serial0 
172.200.0.0/24 is subnetted, 1 subnets 
Cc 172.200.1.0 is directly connected, TokenRing0O 


172.16.0.0/24 is subnetted, 1 subnets 
D —-«-172.16.1.0 [90/2195456] via 192.168.128.5, 00:09:19, Serial0 ‘~ Corp Subnet 
sug_branch# 


sug_branch#show ip eigrp neighbors 
IP-EIGRP neighbors for process 2001 


H Address Interface Hold Uptime SRIT RTO Q Seg 
(sec) (ms) Cnt Num 
0 192..163,128..5 Se0 L2 00209238 32 200 @. 5 


sug_branch# 


After you verify that routes are being exchanged and that an EIGRP neighbor is established, you can 
configure the dial backup portion of the lab. 


Starting with the sub_branch router, follow the four-step process for configuring PPP over 
asynchronous interfaces. The steps to do this are as follows: 


Step 1. Configure the modem and asynchronous port of the router. Use the show line 
command to identify the absolute line number. 


Step 2. Define and configure PPP on the asynchronous interfaces. 
Step 3. Configure IP on the asynchronous interface. 


Step 4. Configure DDR on the asynchronous interface. 


The configuration for the async ports on both routers will be similar to those in past labs, with the 
main difference being that of a routing protocol. Under the async port, you will need to have the 
async default routing command for EIGRP. Because you will be using the backup interface 
command, the dialer list can permit all |P traffic on the sug_branch router. Until the backup 
interface command is added, you will see the link immediately dial if EIGRP is configured. If you 
perform a debug dialer, you will see that an EIGRP multicast is bringing up the dialer, as 
demonstrated in Example 4-33. 
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Example 4-33 Example of debug dialer 


11:25:13: Asyncl: Dialing cause ip (s=192.168.128.10, d=224.0.0.10) | *~ BIGRP 
11:25:13: Asyncl: Attempting to dial 5496870 

11:25:13: CHAT1: Attempting async line dialer script 

11:25:13: CHAT1: Dialing using Modem script: dialsug & System script: none 
11:25:13: CHAT1: process started 

11:25:13: CHAT1: Asserting DTR 

11:25:13: CHAT1: Chat script dialsug started 


On the sug_corp router, there will be no need for a dialer list because this side of the network will not 
be responsible for establishing or maintaining the link. 


Example 4-34 shows the configurations for the SuperGreat network in their entirety. 


Example 4-34 Complete Configurations for SuperGreat Network with Backup 


hostname sug_corp 
! 
enable password cisco 
! 
username sug_branch password 0 cub9biggs 
! 
interface Ethernet0 
ip address 172.16.1.1 255.255.255.0 
! 
interface Serial0 
ip address 192.168.128.5 255.255.255.252 
encapsulation ppp 
no fair-queue 
clockrate 64000 
ppp authentication chap 
! 
interface Asyncl 
ip address 192.168.128.9 255.255.255.252 
encapsulation ppp 
async default routing 
async mode interactive 
dialer in-band 
dialer idle-timeout 300 
dialer map ip 192.168.128.10 name sug_branch broadcast 5496550 
ppp authentication chap 
! 
router eigrp 2001 
network 192.168.128.0 
network 172.16.0.0 
no auto-summary 
! 
ip classless 
! 
line con 0 
line aux 0 
autoselect ppp 
modem InOut 
modem autoconfigure discovery 
transport input all 
rxspeed 38400 
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txspeed 38400 
line vty 0 4 
login 

! 
end 


hostname sug_branch 
! 
enable password cisco 
! 
username sug_corp password 0 cub9biggs 
ip subnet-—zero 
chat-script dialsug "" "ATZ&F" OK "ATDT5496870" TIMEOUT 60 CONNECT 
! 
interface Serial0 
ip address 192.168.128.6 255.255.255.252 
no ip directed—-broadcast 
encapsulation ppp 
no ip mroute-cache 
backup interface Asyncl 
no fair-queue 
ppp authentication chap 
! 
interface TokenRingO 
ip address 172.200.1.1 255.255.255.0 
no ip directed—-broadcast 
ring-speed 16 
! 
interface Asyncl 
ip address 192.168.128.10 255.255.255.252 
no ip directed—-broadcast 
encapsulation ppp 
dialer in-band 
dialer map ip 192.168.128.9 name sug_corp broadcast 5496870 
dialer-group 1 
async default routing 
async mode interactive 
ppp authentication chap 
! 
router eigrp 2001 
network 172.200.0.0 
network 192.168.128.0 
no auto-summary 
! 
ip classless 
! 
dialer-list 1 protocol ip permit 
! 
line con 0 
transport input none 
line aux 0 
autoselect ppp 
script dialer dialsug 
modem InOut 
modem autoconfigure discovery 
transport input all 
speed 38400 
line vty 0 4 
login 
! 
end 
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The SuperGreat network can be tested for backup by unplugging or shutting down the serial interface 
on the corporate end. |! mmediately upon link loss, you should see the branch router call the remote. 
The routing table will then converge over the async interface. Example 4-35 highlights this process in 
effect. 


Example 4-35 Output from debug dialer and Route Table Convergence on 
the sug_ branch Router 


sug_branch#show ip route 
Codes: C - connected, S - static, I - IGRP, R —- RIP, M —- mobile, B —- BGP 
D - EIGRP, EX -— EIGRP external, O -— OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U - per-user static route, o - ODR 
T - traffic engineered route 


Gateway of last resort is not set 


192.168.128.0/24 is variably subnetted, 3 subnets, 2 masks 


D 192.168.128.8/30 [90/70440192] via 192.168.128.5, 00:04:19, Serial0 
Cc 192.168.128.4/30 is directly connected, Serial0 
Cc 192.168.128.5/32 is directly connected, Serial0d 
172.200.0.0/24 is subnetted, 1 subnets 
Cc 172.200.1.0 is directly connected, TokenRing0O 


172.16.0.0/24 is subnetted, 1 subnets 
D _——-172.16.1.0 [90/2195456] via 192.168.128.5, 00:04:43, Serialo  ‘~ corp 


sug_branch# 
sug_branch# 


Bee ee ae ae | i 
11:34:50: SLINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state 


to down 
11:35:06: Asyncl: re-enable timeout 


11:35:06: Asyncl: Dialing cause ip (s=192.168.128.10, d=224.0.0.10)  ‘~ BIGRP forces 
i. Asyncl: Attempting to dial 5496870 

11:35:06: CHAT1: Attempting async line dialer script 

11:35:06: CHAT1: Dialing using Modem script: dialsug & System script: none 

11:35:06: CHAT1: process started 

11335706¢ (CHATIs Asserting DIR 

11:35:06: CHAT1: Chat script dialsug started 

11:35:25: CHAT1: Chat script dialsug finished, status = Success 


11:35:25: CHAT1: Chat script dialsug finished, status = Success 
1ig35:322 dialer Protocol up for Asi 


BESS SES Aa RENEE ROTO SoU e DOWN Hanne rR ERO SOT SOns TRPER Tach a Aaya lyme hanged setars 
“async UP 
sug_branch# 
sug_branch# 
sug_branch#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M —- mobile, B —- BGP 
D — EIGRP, EX -— EIGRP external, O -—- OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U - per-user static route, o - ODR 
T - traffic engineered route 
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Gateway of last resort is not set 


192.168.128.0/24 is variably subnetted, 2 subnets, 2 masks 


C 192.168.128.8/30 is directly connected, Asyncl 
ie 192.168.128.9/32 is directly connected, Asyncl 
172.200.0.0/24 is subnetted, 1 subnets 
Cc 172.200.1.0 is directly connected, TokenRing0O 
172.16.0.0/24 is subnetted, 1 subnets 
D —_—_—-172.16.1.0 [90/69953792] via 192.168.128.9, 00:00:21, Asyncl ‘~ Corp Ethernet 
steele ina USMS 


sug_branch# 
sug_branch#ping 172.16.1.1 


Type escape sequence to abort. 


Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds: 


-_ 


Success rate is 100 percent (5/5), round-trip min/avg/max = 200/238/324 ms 
sug_branch# 
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Chapter 5. WAN Protocols and Technologies: Frame 
Relay 


Frame Relay has become "king of the WAN" over the past five to seven years. Many private 
networks have gone through lengthy migration processes, moving from point-to-point serial 
links to Frame Relay- based networks. As popular as Frame Relay is, its popularity is starting 
to wane. Frame Relay circuits eventually might be replaced by lower-cost, higher-speed 
circuits, such as DSL or cable modems. If a home user can get T3 speed access to Internet 
service providers (ISP), it is only a matter of time before DSL or some other technology using 
existing copper replaces the lower-bandwidth Frame Relay service. But it will be years for a 
new protocol to take the title away from the "king." 


This chapter covers Frame Relay terminology and provides a technical overview of Frame 
Relay and LMI operation. In addition, this chapter examines basic and advanced Frame Relay 
configuration, including Frame Relay traffic shaping. 
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Frame Relay Terminology 


Some common terms are necessary to know when discussing and configuring Frame Relay. 
Some of the terms on the following list are recalled from Chapter 1, "The Key Components 


for Modeling an Internetwork": 


e Permanent virtual circuit (PVC)— The logical end-to-end circuit, used for frame 
transport. A PVC's endpoints are addressed with DLCls. 


e Data-Link Connection Identifier (DLCI)— A logical number in the range of 16 to 
1007 used to identify the PVC between the customer premises equipment (CPE) and 
the Frame Relay switch. The DLCI is only locally significant, which implies that only 
the local devices and the Frame Switch that they attach to care what their DLCI 
numbers are. 


e Local Management Interface (LMI )— Best defined as the signaling standard used 
between the router and the Frame Relay switch. LMI is used by the switch to learn 
which DLCls are defined and what their status is. LMI also supports a 10-second 
keepalive mechanism that verifies that the PVC is active and data is being exchanged. 
Three types of LMI are supported on Cisco routers: CISCO, ANSI, and Q933A. If LMI 
is not configured, the router tries to autonegotiate on all three LMI types: 


- C1SCO— LMI type defined by the "big three," Cisco, Digital, and Northern 
Telecom. This is the default LMI type, if autonegotiation fails. LMI status 
information is sent on DLCI 0. 


- ANSI — LMI type defined by ANSI standard T1.617, commonly called Annex 
D. This is the most common type of LMI found across all Frame Relay 
networks. LMI status information is sent on DLC! 1023. 


- Q933a— LMI type defined as ITU-T Q.933, or simply Annex A. LMI status 
information is sent on DLCI 0. 


e Network-to-Network I nterface (NNI)— The standard used for two switches to 
communicate. NNI is used in both Frame Relay and ATM. In ATM, it is referred to as 
the Network Node Interface. 


e Local access rate— The clock speed or "port speed" of the connection to the Frame 
Relay service provider. Usually, this circuit is 56 kbps, 64 kbps, or Tl speeds, but can 
operate T3 speeds or on High Speed Serial Interface (HSSI). 


Figure 5-1 illustrates a common Frame Relay network, highlighting the preceding terms. 


Figure 5-1. Partially Meshed Frame Relay Network 
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The following terms are called data rate metrics. Frame Relay service providers use data rate 
metrics to define service-level agreements. The following terms also are used when we 
configure Frame Relay traffic shaping: 


e Committed burst (Bc)— The number of bits committed to accept and transmit at 
the CIR. 


e Committed Information Rate (CIR) The maximum permitted traffic level per PVC. 
When this is exceeded, the Discard Eligible (DE) bit is set. The DE bit can be used as 
an indication to the frame carrier that it can drop that frame if capacity between 
Frame Relay switches is reached. This value is expressed in bits per second. 


e Excess burst (Be)— The number of bits to transmit after the committed burst value 
is reached. 


e Maximum data rate (MaxR)— This value is measured in bits per second and is 
calculated by the following: 


Bc+Be 


MaxR = CIR x 
Be 


Figure 5-2 illustrates how these metrics relate to each other. 
Figure 5-2. Frame Relay Data Metrics 
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Frame Relay Technical Overview 


Necessity is the mother of invention, and this old rule applies to protocols as well. There were 
many shortcomings in X.25, SDLC, and other WAN protocols when Frame Relay surfaced. 
Frame Relay brought many useful options that aided in better network design, such as the 
following: 


e Frame Relay provides a means for statistically multiplexing many logical circuits over 
a single physical circuit. 

e Frame Relay helps lower line cost by not requiring dedicated end-to-end circuits for 
each link. 

e Statistical multiplexing provides for increased network scalability by eliminating the 
need for a router serial port and CSU/DSU for each side of the connection. 

e Frame Relay has a scalable network design: 


- It adheres to the three-layer model—core, distribution, and access layers. 
- It allows full, partial, and hybrid meshing strategies. 
- It adds protocol broadcast and performance controls. 


Frame Relay is a CCITT and American National Standards Institute (ANSI) standard. It was 
founded as the next-generation protocol to X.25, which sometimes is referred to as an 
overengineered protocol because it performs extensive error checking and correction at the 
data link and network layers. X.25 had this type of error correction because it had to deal 
with many low-quality lines. Frame Relay implements a connection-oriented data stream that 
relies on the upper-layer protocols to provide error checking and correction. For reference, 
Frame Relay is outlined in the following standards: 


e ANSI T1.606: "Architectural Framework and Service Description for Frame-Relaying 
Bearer Service" (1991) 


e ANSI 171.617: "Signaling Specification for Frame Relay Bearer Service" (1991) 


e ANSI T1.618: "Core Aspects of Frame Protocol for Use with Frame Relay Bearer 
Service" (1991) 


e ITU Q.933 and Q.922: User plane control 
e RFC 1490: Defines Frame Relay encapsulation 


A number of Frame Relay Forum (FRF) implementation agreements can be found at www. 
frforum.com. 


Frame Relay LMI Operation 


The LMI is essential for Frame Relay operation. When a Frame Relay link becomes active on a 
Cisco DTE device, it sends three LMI messages in rapid succession. The order is ANSI, ITU, 
and then Cisco. The router listens on DLC! 1023 for Cisco LMI and DLC! O for ANSI and ITU. 


364 


The Frame switch responds with the LMI with which it is configured, and the router then sets 
the LMI type of that interface to match the LMI type that it received. If multiple types of LMI 
are received, the last one received is used. Cisco refers to this as LMI autosense. The router 
then sends LMI status messages back and forth every 10 seconds. These status messages 
are referred to as LMI keepalives. The router then begins to operate in the manner illustrated 
by Figure 5-3 and explained in the list that follows. 


Figure 5-3. Frame Relay LMI Operation 
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1. On every sixth LMI status request, the DTE device sends a full status request. This 
request serves as another keepalive and requests the frame switch to respond with a 
list of all DLCls that have been defined for that link. Example 5-1 shows this initial 
exchange happening. 


Example 5-1 Initial LMI Setup and Exchange Output from debug 
frame Imi and debug frame packet 


00:19:19: datagramstart = 0x400002DC, datagramsize = 14 
00:19:19: FR encap = 0x00010308 

OOL1T 919s OO 75 9S 01-0100 08 02-02. 00 

GOs 19s 19%: 


00:19:19: datagramstart = 0x4000053C, datagramsize = 13 
00:19:19: FR encap = 0x00010308 

OOS L9t1 9s: 00 75 51 OL. 00 5302-07. 00 

00:19:19; 


00:19:19: datagramstart = 0x400002DC, datagramsize = 13 
365 


00:19:19: FR encap = OxFCF10309 
OO 19:19: 00 75 01. 01.00 03 02 01 00 
COLL Os 1 oO 


00:19:19: RT IE 1, length 1, type 0 
00:19:19: KA IE 3, length 2, yourseq 1 , myseq 1 


00:19:29: SerialO (out): StEnq, myseq 2, yourseen 1, DTE up 
00:19:29: datagramstart = 0x400002DC, datagramsize = 13 
00:19:29: FR encap = OxFCF10309 

OOrT Is 293 O08 7S: OL O01 Ol OS: .02 02-01: 

OOLLOs2 9% 

00:19:29: SerialO(in): Status, myseq 2 

00:19:29: RT IE 1, length 1, type 0 

00:19:29: KA IE 3, length 2, yourseq 2 , myseq 2 

OOLL9s29% PVC TE Ox? ,. Length 0x6 ,. dici 110, sitatus. 0x0 , bw 0 


2. When the frame switch receives a status inquiry message, it sends a full status 
response. This message sends a list of all active DLCls on that port. 


3. For each active DLCI, the router sends an Inverse ARP request per Layer 3 protocol 
configured on that interface. If |P and IPX are configured, for example, the router 
sends two Inverse ARP requests. The request also asks the other router to reply with 
its network layer address. If Inverse ARP is not supported, this transaction and the 
transaction that follows are accomplished with the frame-relay map commands 
(covered in the "Configuring Frame Relay" section). 


4. For each DLCI that each router receives an Inverse ARP message about, the router 
creates a map entry in its Frame Relay map table. The map table includes the local 
DLCI and the remote router's network layer address for that request. The table also 
contains the status of the PVC, which is one of the following (as displayed with the 
show frame-relay pvc command): 


- ACTIVE— Indicates that the PVC is active and that information can be 
exchanged 


- INACTIVE— Indicates that the local connection to the Frame switch is 
working, but the remote router's connection to the frame switch is not working 


- DELETED— Indicates that no LMI is being received from the frame switch or 
that the physical layer is still not established 


5. The router continues to exchange keepalive messages every 10 seconds. Again, every 
60 seconds, or sixth exchange, a full status LMI request is sent and the process 
repeats itself. If three consecutive LMI messages are missed, the link is brought down. 


366 


Configuring Frame Relay 


You need to follow only two physical steps when configuring Frame Relay on Cisco routers. In this 
text, we list a four-step process; some of these steps do not require configuration. Regardless, you 
should always be aware of all the components or steps needed to configure the complete frame 
service. A couple of these commands are set by default, and no additional key-ins are necessary. 
Further additional steps can be added to the basic steps, but they are not required to get frame 
service running on your router. 


Step 1. Enable Frame Relay encapsulation on an interface or subinterface. This is 
done with the following interface command: 


router (config-if) #encapsulation frame-relay [cisco | ietf] 

cisco is the default encapsulation type and should be used when connecting to another 
Cisco device or an RFC 1490-compliant device. 

ietf should be used when connecting to non-Cisco devices. 


Step 2. Set the LMI type. All Cisco routers running Cisco |OS Software Release 11.2 and 
later support LMI autosense and require no additional configuration. You can statically 
configure the LMI with the following interface command: 


Router (config-if) #frame-relay lmi-type [ansi | cisco | q933i] 


Refer back to the descriptions on different LMI types in the "Frame Relay Terminology" 
section if you need to refresh your memory. Cisco is the default LMI type. 


Step 3. Configure static or dynamic protocol and address mapping. Next, determine 
what type of address mapping is needed for the specific Frame Relay interface. Your choice 
to use frame-relay map command versus frame-relay interface-dlci or no command at 
all depends on how you have the Frame Relay interface configured and whether the remote 
device supports Frame Relay Inverse ARP. Subinterfaces are logical divisions of the physical 
interface. Dynamic address mapping uses Frame Relay Inverse ARP, as previously 
mentioned. Because you are now splitting the physical interface into multiple subinterfaces, 
you must provide additional configuration information that ties a specific subinterface to a 
specific DLCI. Two types of subinterfaces exist in Frame Relay networks, point-to-point and 
multipoint. If you are creating a point-to-point subinterface, use the following command: 


Router (config-if) #frame-relay interface-dlci dlci_number 


When you are creating a multipoint interface, you need to use static addressing. This is not 
as much for Frame Relay purposes as it is for general routing issues. Inverse ARP will still 
be resolved; however, routed protocols will not be capable of forwarding packets to the 
appropriate next-hop address without the aid of static addressing. Use the following 
command on multipoint interfaces: 


Router (config-if) #frame-relay map protocol [ip | dec | appletalk | xns | ipx | 
vines | clns | bridge | 1llc2 | dlsw] next_hop_address dlci [broadcast] 
[ietf£ | cisco] 


The frame-relay map statement creates a static map between the local DLCI and the 
next-hop network address. The broadcast keyword is required to forward specific 
broadcasts, such as the ones needed for OSPF. This keyword should be used at all times. 
The ietf and cisco keywords allow for different frame encapsulation types on a a 


The frame-relay map statement also can be used to load-share traffic over a frame 
network. For example, I PX traffic can be mapped to one DLCI, while |P can be mapped to 
the other. This command also is used to transport protocols in accordance with RFC 1490, 
such as Spanning-Tree frames and Data Link Switching frames. This command has many 
uses; refer to the Cisco |OS Software Configuration Guide for all frame-relay map 
command options. 


Table 5-1 illustrates the recommended use of Inverse ARP address mapping type for each 


interface. 


Table 5-1. Recommend Address Mapping and Inverse ARP 
Pairings 


Natural or 
Standard 
Interface 


Multipoint 
Subinterface 


Add a network 
layer address for 
each protocol. Use 
frame-relay map 
statements. 


Adda 
network layer 
address for 
each protocol. 


Static or 
dynamic 


Static addressing 


Point-to- 
Point 
Interface 


Adda 
network layer 
address for 
each protocol. 
Use the 
frame-relay 
interface- 


Dynamic 
addressing 


Connecting to 
a Device 
Without 

Inverse ARP 


Add a network 
layer address 
for each 
protocol. Use 
frame-relay 
map 
statements. 


Static 
addressing 


addressing 


Step 4. Address protocol-specific issues. You need to be aware of certain issues when 
configuring routing protocols over Frame Relay. For example, OSPF works properly only 
with the network type changed or with neighbor statements. All multipoint networks 
running distance vector protocols, or EIGRP, are subject to split horizons. We discuss these 
issues in more detail in upcoming chapters. Table 5-2 lists common issues to address with 
Frame Networks. 


Table 5-2. Common Issues with Frame Networks 


Point-to-Point 
Interface 


Protocol; Multipoint Subinterface 
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OSPF Must use neighbor 
statements, or use the ip 
ospf network type 
command on the interface. 
Use a priority of 1 to set the 
DR router. This should be the 
router with a PVC to all of its 


neighbors. 


Must use neighbor 
statements, or use the ip 
ospf network type 
broadcast, or ip ospf 
network type point-to- 
point command on the 
interface. 


EIGRP Disable IP or IPX split horizons. Add bandwidth 
command. 
Add bandwidth command. 
RIP Disable IP or IPX split 


horizons. 
Disable IP or IPX split horizons. 


Add bandwidth 
command. 


Add bandwidth command. 


[None. None. 


Bridging |Set the root bridge to the Set the root bridge to the 
router that has PVCs to all router that has PVCs to 
leaves of the bridge. all leaves of the bridge. 


NOTE 


Split horizon refers to the rule that information about a route will not be sent out the 
same interface or subinterface from which it was received. Split horizon rears its ugly 
head most predominantly in multipoint configurations. Here, routing updates flow into 
one subinterface but also must be sent out that same subinterface to reach the other 
routers on the multipoint network. Split horizon is on by default and prevents routing 
updates for EIGRP, IGRP, and RIP from being propagated properly in a multipoint 
configuration. Disable this with the following interface key-in: no ip split-horizon for 
RIP or IGRP networks, and no ip split-horizon eigrp autonomous system for EIGRP 
networks. These commands have similar forms for IPX and AppleTalk. If you have two 
point-to-point subinterfaces configured, routing updates flow in one subinterface and 
are forwarded out the other subinterface because each subinterface is on a different 
network. Therefore, there is no need to disable split horizon when using point-to-point 
subinterfaces. 


Practical Example: Configuring Hybrid Frame Relay Networks 


The example that follows walks you through the complete configuration of a Frame Relay network 
by using the different types of interfaces. Figure 5-4 illustrates a hybrid Frame Relay network. 


Figure 5-4. Frame Relay Hybrid Network 
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In this example, you configure a Frame Relay multipoint network between the marlin, glock, and 
sig routers. You also configure a Frame Relay point-to-point network between the marlin and the 
bushmaster routers. The routing protocol is |GRP. 


Let's begin with the marlin router. Following the four-step Frame Relay configuration process, start 
by setting the encapsulation to Frame Relay on the serial interface. You define two types of 
subinterfaces. A multipoint is needed for the subnet 172.16.1.0/24, which connects the glock and 
sig routers. You can use a point-to-point or a multipoint for subnet 172.16.16.0/24 to connect to 
the bushmaster router. 


In this example, you use a point-to-point network. Example 5-2 demonstrates this configuration. 


Example 5-2 Setting Encapsulation and Defining Subinterfaces 


marlin#tconf t 

Enter configuration commands, one per line. End with CNTL/Z. 
marlin(config) #int sO 

marlin(config-if) #encapsulation frame-relay 
marlin(config-if) #int s0.1 multipoint 
marlin(config-subif) #ip address 172.16.1.1 255.255.255.0 
marlin(config-subif) #exit 

marlin(config) #int s0.2 point-to-point 
marlin(config-subif) #ip address 172.16.16.1 255.255.255.0 
marlin(config-subif) #*Z 
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You can follow the same steps defining a multipoint subinterface on the glock router and a point-to- 
point subinterface on the bushmaster router. You will not use any subinterfaces on the glock 
router, and you should treat it as a multipoint router. At this time, you need only to define the 
Frame Relay encapsulation on the glock router's sO interface. 


The next step is to configure LMI. As previously mentioned, Frame Relay autosense detects and 
configure the LMI automatically. No additional configuration is needed. For practice, you will 
statically configure the LMI on the bushmaster router to ANSI. This is accomplished with the 
frame-relay Imi-type ansi command under the sO interface. 


The third step is to configure static or dynamic addressing. On the marlin router, use a static 
address on the sO.1 interface, the multipoint interface. The s0.2 interface is a point-to-point 
interface, so you can use dynamic addressing. You need one frame-relay map statement pointing 
to each remote router on the 172.16.1.0/24 subnet. Example 5-3 demonstrates the configuration 
for static mapping. 


Example 5-3 Configuring Static Mapping 


marlin(config) #int s0.1 multipoint 

marlin(config-subif) # frame-relay map ip 172.16.1.3 110 broadcast 
marlin(config-subif) # frame-relay map ip 172.16.1.5 120 broadcast 
marlin(config-subif) #exit 


Example 5-4 demonstrates the configuration of dynamic addressing needed for the marlin router. 


Example 5-4 Configuring Dynamic Mapping 


marlin(config) #int s0.2 point-to-point 
marlin(config-subif) #frame-relay interface-dlci 130 
marlin(config-—fr—dlci) #*Z 

marlin# 


The glock router's serial interface is a natural interface on a multipoint network; therefore, you use 
static addressing. Here, you need two frame-relay map statements. You configure one frame- 
relay map statement pointing at DLCI 111 for IP address 172.16.1.1, and one pointing at the 
same DLCI, 111, for |P address 172.16.1.5. Example 5-5 shows the configuration on the glock 


router serial interface. 


Example 5-5 Configuring the glock Router's Serial I nterface 


Interface serial0 

ip address 172.16.1.3 255.255.255.0 

no ip directed—-broadcast 

encapsulation frame-relay 

no ip mroute-cache 

no fair-queue 

frame-relay map ip 172.16.1.5 111 broadcast 
frame-relay map ip 172.16.1.1 111 broadcast 


The sig router has a multipoint subinterface on sO; therefore, this router also needs two static 
frame-relay map statements. One frame-relay map statement is for the glock router, and one 
is for the marlin router. Example 5-6 shows the configuration for the serial interface for the sig 
router. 
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Example 5-6 sig Router's Serial Interface 


interface serial0.1 multipoint 

ip address 172.16.1.5 255.255.255.0 

no ip directed—-broadcast 

no ip mroute-cache 

frame-relay map ip 172.16.1.3 121 broadcast 
frame-relay map ip 172.16.1.1 121 broadcast 


Returning to the marlin router, you can complete Step 3 for the point-to-point side of the link. The 
subinterface sO.2 is a point-to-point interface to the bushmaster router. Therefore, you can use 
dynamic addressing on this interface. To accomplish this, use the frame-relay interface-dlci 
dici_ number command under the sO.2 interface, such as in Example 5-7. 


Example 5-7 Configuring marlin Router's serial 0.2 Subinterface 


interface serial0.2 point-to-point 
ip address 172.16.16.1 255.255.255.0 


Repeat this same process for the point-to-point subinterface on the bushmaster router; this time, 
however, it points toward DLCI 131. 


Now, you can move on to Step 4 in the configuration process: address any protocol-specific issues. 
As previously mentioned, a split-horizon issue occurs on a multipoint network running |GRP, such 
as this one. With the default of split horizon set to on, the marlin router will not forward sig's 
Ethernet network of 172.16.5.0/24 back out the sO.1 port toward the glock router. It also will not 
forward the glock router's Token Ring network 172.16.3.0/24 back out its sO.1 port toward the sig 
router. To resolve this, use the no ip split-horizon command on the marlin router's sO.1 port. 
You now have full IP connectivity across the Frame Relay network. |GRP uses bandwidth to 
influence routing decisions. To further tune the network, assign bandwidth statements to all 
serial interfaces to make routing decisions more accurate. Example 5-8 lists the relevant portions 


of all the router configurations. 
Example 5-8 Relevant Configuration Listing for the Routers in Figure 5-4 


hostname marlin 
' 


interface Ethernetl 

ip address 172.16.2.1 255.255.255.0 
media-type 10BaseT 

! 
interface Serial0O 

no ip address 

encapsulation frame-relay 

no ip mroute-cache 

bandwidth 1544 

no fair—queue 

! 

interface Serial0O.1 multipoint 

ip address 172.16.1.1 255.255.255.0 

no ip split—horizon 

frame-relay map ip 172.16.1.3 110 broadcast 

372 


frame-relay map ip 172.16.1.5 120 broadcast 
! 

interface Serial0.2 point-to-point 

ip address 172.16.16.1 255.255.255.0 
frame-relay interface-dlci 130 

! 

router igrp 2001 

network 172.16.0.0 

! 


hostname glock 
! 
<<<text omitted>>> 
! 
interface Serial0O 
bandwidth 64 
ip address 172.16.1.3 255.255.255.0 
no ip directed—broadcast 
encapsulation frame-relay 
no ip mroute-cache 
no fair-queue 
frame-relay map ip 172.16.1.5 111 broadcast 
frame-relay map ip 172.16.1.1 111 broadcast 
! 
interface TokenRingO 
ip address 172.16.3.3 255.255.255.0 
no ip directed-—broadcast 
ring-speed 16 
! 
router igrp 2001 
network 172.16.0.0 
! 


hostname sig 
! 
<<<text omitted>>> 
! 
interface Ethernet0O 
ip address 172.16.5.5 255.255.255.0 
no ip directed—broadcast 
! 
interface Serial0O 
no ip address 
no ip directed-—broadcast 
encapsulation frame-relay 
no ip mroute-cache 
no fair-queue 
! 
interface Serial0.1 multipoint 
bandwidth 64 
ip address 172.16.1.5 255.255.255.0 
no ip directed—broadcast 
no ip mroute-cache 
frame-relay map ip 172.16.1.3 121 broadcast 
frame-relay map ip 172.16.1.1 121 broadcast 
! 
router igrp 2001 
network 172.16.0.0 
! 
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hostname bushmaster 
! 


interface Ethernet0O 
ip address 172.16.6.6 255.255.255.0 
! 
interface Serial0 
no ip address 
encapsulation frame-relay 
frame-relay lmi-type ansi 
! 
interface Serial0.1 point-to-point 
ip address 172.16.16.6 255.255.255.0 
bandwidth 64 
frame-relay interface-dlci 131 
! 
router igrp 2001 
network 172.16.0.0 


To verify that your Frame Relay network is operational, you can use standard pings and traces 
tests; however, sometimes you might want to require more information about the operational 
status of the Frame network. The "Big show" and "Big D" commands for Frame Relay can provide 
a lot of useful information, as described in the next section. 
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The "Big show" and "Big D" for Frame Relay 


The show and debug commands for Frame Relay are some of the most useful Cisco commands. 
They allow you to quickly isolate most problems, and they don't seem to provide excess data that 
doesn't help you troubleshoot or verify whether the service is running. The "Big show" and "Big D" 
commands for Frame Relay are as follows: 


show frame-relay pve [dlci | interface] 
show frame-relay lmi 
show frame-relay map 
debug frame-relay lmi 


NOTE 


For a complete list of the show and debug commands for Frame Relay, see the |OS 
WAN Configuration Guide. 


show frame-relay pvc Command 


The show frame-relay pvc command displays the statistics about all PVCs on the router, or an 
optional keyword can be used to display information on a specific DLCI or interface. Most of this 
command's information is self-explanatory—it shows traffic rates in the form of packets and bytes. 
It also displays any forward-explicit congestion notification/backward- explicit congestion 
notification (FECN/BECN) information along with DE packets. The section "Configuring Frame Relay 


Traffic Shaping (FRTS)" discusses FECN/BECN in more details and gives some additional 
information that the show frame pvc command displays. 


One of the key fields to look for is the PVC status. As mentioned previously, the PVC status can be 
one of the following: 


e ACTIVE— Indicates that the PVC is active and that information can be exchanged 


e INACTIVE— Indicates that the local connection to the frame switch is working but that the 
remote router's connection to the frame switch is not working 


e DELETED— Indicates that no LMI is being received from the frame switch or that the 
physical layer is not established 


Example 5-9 lists the output from the show frame pvc command from the marlin router in the 
previous example. Notice that traffic is passing on the link, and the PVC status is ACTIVE. 


Example 5-9 show frame pvc Output from the marlin Router 


marlin#show frame-relay pvc 
PVC Statistics for interface Serial0O (Frame Relay DTE) 


input pkts 500 output pkts 250 in bytes 62900 
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out bytes 29762 

in BECN pkts 0 

in DE pkts 0 

out. beast pkts 25.0 


input pkts 498 

out bytes 29670 

in BECN pkts 0 

in DE pkts 0 

out bcast pkts 249 


input pkts 585 
out bytes 118208 
in BECN pkts 0 


dropped pkts 2 
out FECN pkts 0 
out DE pkts 0 
out bcast bytes 29762 


output pkts 249 
dropped pkts 0 
out FECN pkts 0 
out DE pkts 0 
out bcast bytes 29670 


output pkts 590 
dropped pkts 0 
out FECN pkts 0 


in FECN pkts 0 
out BECN pkts 0 


in bytes 27132 
in FECN pkts 0 
out BECN pkts 0 


in bytes 107506 
in FECN pkts 0 
out BECN pkts 0 


in DE pkts 0 
out bcast pkts 590 


out DE pkts 0 
out bcast bytes 118208 
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The PVC Create Time and the Last Time PVC Status Changed fields are also important. These times 
should be relatively close if your PVC has not dropped since the interface was brought up. Example 
5-10 lists the output of the marlin router with a problem on the PVC. Can you guess where the 
problem might be just by this one command? 


Example 5-10 Output of show frame pvc Command on the marlin Router 
with a PVC Down 


marlin#show frame pvc 


PVC Statistics for interface SerialO (Frame Relay DTE) 


input pkts 508 

out bytes 30362 

in BECN pkts 0 

in DE pkts 0 

out beast pkts 255 


DLCI = 120, DLCI USAGE 


input pkts 508 

out bytes 30270 

in BECN pkts 0 

in DE pkts 0 

out bcast pkts 254 


pvc create time 05:38:01, 


DLCI = 130, DLCI USAGE 


input pkts 595 
out bytes 120372 


LOCAL; 


output pkts 255 
dropped pkts 2 
out FECN pkts 0 
out DE pkts 0 
out bcast bytes 30362 


output pkts 254 
dropped pkts 0 
out FECN pkts 0 
out DE pkts 0 
out bcast bytes 30270 


PVC STATUS = ACTIVE, 


in bytes 63860 
in FECN pkts 0 
out BECN pkts 0 


INTERFACE = Serial0O.1 


in bytes 27632 
in FECN pkts 0 
out BECN pkts 0 


last time pvc status changed 05:35:49 


LOCAL, PVC STATUS = ACTIVE, 


output pkts 601 
dropped pkts 0 


INTERFACE = Serial0.2 


in bytes 109422 
in FECN pkts 0 


in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 

in DE pkts 0 out DE pkts 0 

out bcast pkts 601 out bcast bytes 120372 

pve create time 05:38:01, last time pvc status changed 05:37:09 
marlin# 


Notice that the PVC 110 status has changed. The PVC status is now INACTIVE. Because the other 
PVC, DLCI 120 on interface Serial0.1, is up and the status of 110 is inactive, it indicates a problem 
at the remote end. In this example, the glock router's serial interface was shut down, again 
proving that even in a lab setting, "carrier gremlins" do exist. 


show frame-relay Imi Command 


Everything that rides over Frame Relay rides over the LMI. If the LMI is not working properly, your 
frame service will not work. When using the show frame-relay Imi command, look for the Num 
Status Enq. Sent xx to increment with the Num Status msgs Rcvd xx field. If you are sending LMI 
but are not receiving it, the problem is likely to be with the frame switch or an LMI mismatch. 
Ensure that the LMI for the interface is the same as what the carrier has the switch set for. 
Example 5-11 lists the output from the glock router demonstrating an LMI mismatch. Observe how 


the LMI is being sent, and notice that timeouts are increasing. 


Example 5-11 LMI Mismatch Demonstrated with the show frame Imi 
Command 


glock#show frame lmi 


LMI Statistics for interface Serial0O (Frame Relay DTE) LMI TYPE = ANSI 


Invalid Unnumbered info 0 Invalid Prot Disc 0 
Invalid dummy Call Ref 0 Invalid Msg Type 0 
Invalid Status Message 0 Invalid Lock Shift 0 
Invalid Information ID 0 Invalid Report IE Len 0 
Invalid Report Request 0 Invalid Keep IE Len 0 


glock#show frame lmi 


LMI Statistics for interface Serial0O (Frame Relay DTE) LMI TYPE = ANSI 


Invalid Unnumbered info 0 Invalid Prot Disc 0 

Invalid dummy Call Ref 0 Invalid Msg Type 0 

Invalid Status Message 0 Invalid Lock Shift 0 

Invalid Information ID 0 Invalid Report IE Len 0 

Invalid Report Request 0 Invalid Keep IE Len 0 
Pee ae ee OE gta | nner Uc ee 
GRR ORGS Hes bee Use eal ee OES USMS UEneoubSas 
gGlock# 


After changing the LMI to Cisco and performing a clear counters command, you can see what a 
proper running line looks like. Notice this time in Example 5-12 that the Num Status Enq. Sent 


messages are incrementing with the Num Status Msgs Rcvd field. 


Example 5-12 show frame Imi Command Output 


glock#show frame lmi 


LMI Statistics for interface Serial0O (Frame Relay DTE) LMI TYPE = CISCO 
Invalid Unnumbered info 0 Invalid Prot Disc 0 


377 


Invalid dummy Call Ref 0 Invalid Msg Type 0 
Invalid Status Message 0 Invalid Lock Shift 0 
Invalid Information ID 0 Invalid Report IE Len 0 
Invalid Report Request 0 Invalid Keep IE Len 0 
Num Update Status Rcvd 0 Num Status Timeouts 0 


glock# 
glock#show frame lmi 


LMI Statistics for interface Serial0O (Frame Relay DTE) LMI TYPE = CISCO 


Invalid Unnumbered info 0 Invalid Prot Disc 0 

Invalid dummy Call Ref 0 Invalid Msg Type 0 

Invalid Status Message 0 Invalid Lock Shift 0 

Invalid Information ID 0 Invalid Report IE Len 0 

Invalid Report Request 0 Invalid Keep IE Len 0 

Num Update Status Rcvd 0 Num Status Timeouts 0 
glock# 


show frame-relay map Command 


The show frame-relay map command displays the network layer address and associated DLCI 
for each remote destination that the local router is connected to. It also displays whether the 
association is dynamic or static. Use this command to verify your frame-relay map statements 
and to check the operation of Inverse ARP. Example 5-13 demonstrates sample output from this 
command. 


Example 5-13 show frame-relay map Command Output 


marlin#show frame-relay map 

Sérial0.1 (up): ip 172.16.1.3 dl¢ci 110(0x6E,0x18E0), static, 
broadcast, 
CISCO, status defined, active 

Sérial0.1 (up): ip 172.16.1.5 dlcei 120(0x78,0x1C80), static, 
broadcast, 
CISCO, status defined, active 

Serial0.2 (up): point-to-point dlci, dilci 130(0x82,0x2020), broadcast 

status defined, active 
marlin# 


debug frame-relay Imi Command 


Although many debug commands are available for Frame Relay, most of them are for specific 
configuration types and don't apply to a majority of general frame configurations. Debugging LMI, 
however, can be helpful for many, if not all, Frame Relay configurations. 


The debug frame-relay Imi command is useful in displaying LMI exchanges. It allows you to 
quickly determine whether the router is properly exchanging LMIs. When using this command, look 
for the yourseq and the myseq numbers to increment. When the router receives a sequence 
number, it adds 1 to it and sends it back out on the next update as its current sequence number. If 
three of these LMI messages, or keepalives, are missed consecutively, the link will be reset. 


If the output from this command shows only one number changing, it is a strong indication of an 
LMI mismatch. If no messages appear, there is poor connection between the router and the frame 
switch. Example 5-14 demonstrates a properly working frame circuit. 
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Example 5-15 exhibits what happens to a link after carrier gremlins cause an LMI mismatch. 


Example 5-14 debug frame-relay Imi Command Output on an Operational 
Frame Circuit 


sigtdebug frame-relay lmi 


18:48:30: datagramstart = OxE23E94, datagramsize = 13 
18:48:30: FR encap = OxFCF10309 
18:48:30: 00 75 01-01 01 03 02 26 25 


18:48:30: RI IE 1, length 1, type 1 
18:48:30: KA IE 3, length 2, yourseq 38, myseq 38 


18:48:40: datagramstart = OxE23E94, datagramsize = 13 
18:48:40: FR encap = OxFCF10309 
18:48:40: 00 75 01 01 01 03 02 27 26 


18:48:40: RT IE 1, length 1, type 1 
18:48:40: KA IE 3, length 2, yoursegq 39, myseq 39 


Example 5-15 debug frame-relay Imi Command Output Demonstrating an 
LMI Mismatch 


sigtdebug frame-relay lmi 


18:59:26: datagramstart = OxE23E94, datagramsize = 13 
18:59:26: FR encap = OxFCF10309 

183592265 00 75. OL O01 03 02.07 ‘05 

18:59326% 


18:59:36: datagramstart = OxE23E94, datagramsize = 13 
18:59:36: FR encap = OxFCF10309 

18:59:36: 00 75 OL O01 01 03 02 08 05 

183 S9F36: 


datagramstart OxE23E94, datagramsize = 13 
18:59:46: FR encap = OxFCF10309 
18359246 00 7501-01 01 03° O02. 09 ‘05 


datagramstart = OxE23E94, datagramsize = 13 
18:59:56: FR encap = OxFCF10309 


1Ss59156s 00-75 01 01 01 03 02 01.05 
379 


183592563 
18:59:57: SLINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state 
to down 
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Additional Commands for Configuring Frame Relay 


Some additional commands are available to control or modify your Frame Relay network. The 
following list includes some of the more commonly tuned features of Frame Relay. For a 
complete list, see the 1|OS WAN Configuration Guide. 


e Router(config-if)no frame-relay inverse-arp— Disables the sending of Inverse 
ARP requests. Use this command in conjunction with no arp frame-relay to prevent 
the dynamic mapping of PVCs. 


e Router(config-if)no arp frame-relay— Disables ARP responses. Use this in 
conjunction with the no frame-relay inverse-arp command. 


e Router(config-if) keepalive keepalive_interval_in_seconds— Sets the default 10- 
second keepalive interval to another value. Be sure to use this command on both 
sides of the link. 


e clear frame-relay-inarp— Use this command to clear any dynamically created 
Frame Relay maps. 


e frame-relay priority-dici-group group-number high-dlci medium-dlci normal-dlci 
low-dlci— Use this command to use multiple parallel DLCls for different Frame Relay 
traffic types. 


381 


Configuring Frame Relay Traffic Shaping 


Traffic shaping works on the principle that a router controls outbound traffic to match its data flow 
to the speed of the remote device. Traffic that fits a particular profile can be "shaped" to meet 
downstream requirements, eliminating downstream bottlenecks. For example, in Figure 5-5, you can 


see a partially meshed Frame Relay network. 


Figure 5-5. Partially Meshed Frame Relay Network 


Remote site Remote site 
Remote site 


In this model, the remote sites need IP access to the authorization center. At any given time, there 
are 300 end-to-end TCP connections from the remote sites to the authorization center. If the link 
between the authorization center fails and then quickly recovers, a flood of TCP connection requests, 
followed by application data, quickly saturating the 64-kbps link from the host site to the 
authorization center. Because the remote sites have a full T1, they send at this speed. They have no 
information letting them know that the authorization center operates at only 64 kbps. FRTS enables 
you to control bursts of traffic that can occur during these situations. 


Let's recall the terms discussed earlier and define them in terms of relevance toward FRTS: 


e Committed burst (Bc)— The amount of data to send in each Tc interval, measured in bits. 
Usually set to 1/8 of CIR. 


e Excess burst (Be)— The number of excess bits to transmit during the first interval over and 
above Bc, only if credit is built up. The Be bit gets set to whatever the burst eligible is set for 
in the Frame Relay switch. The Be bit is optional. In the field, these parameters are supplied 
from the WAN provider. 


e Committed Information Rate (CIR)— The average rate that you want to send traffic out. 
In this case, this is not that same as the CIR provided by the carrier, but it should be set the 
same as the physical port speed. 

e Time Interval (Tc)— Time interval, which cannot exceed 125ms. Tc = Bc/CIR. 
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e MinClR— The minimum amount of data to be sent during periods of congestion. This value 
should be set to your actual CIR that the carrier provides you. 


e Byte increment— This value equals Bc/8. It is the amount of data to send during each time 
interval. 


e FECN/ BECN— There are two bits in the address field of each frame for explicit signaling, 
FECN and BECN. The bits might be set by the frame provider when it detects congestion. The 
frame provider must not clear the bits if it receives a frame with one or both bits set, thereby 
providing true signaling to the end user. 


- Backward-explicit congestion notification (BECN)— This tells the end user that 
congestion- avoidance procedures should be initiated for traffic destined toward the 
opposite direction from which the frame was received. Further frames that the user 
transmits on this VC in this direction might encounter congestion. 


- Forward-explicit congestion notification (FECN)— This tells the end user that 
congestion- avoidance procedures should be initiated for traffic destined toward the 
same direction from which the frame was received. It also means that this frame on 
this VC has encountered congestion. 


When traffic shaping is enabled, the router checks to see whether there is a token or credit available 
before sending the packet. The token bucket has tokens put in at a certain rate. The bucket itself 
also has a predefined capacity. If the bucket is already full of tokens, new tokens cannot be held and 
made available for future packets. Therefore, at any given time, the burst from the router is about 
the same size as the token bucket. If there are not enough tokens for the router to send a packet, 
the packet waits until the bucket has enough tokens, or it is discarded. Before the packet is sent out 
an interface, it is sent through the queue that has been set up for that VC. The default queue is 
FIFO, but custom queuing or priority queuing also can be used. For more information on queuing, 
see Cisco |OS 12.0 Quality of Service, from Cisco Press. 


BECN response mode is one form of traffic shaping. With BECN response mode, traffic shaping is 
enabled. If a router receives any BECNs during the current time interval, it decreases its transmit 
rate by 25 percent. This rate continues to drop by 25 percent once per Tc interval until the traffic 
rate gets to MinCIR, where it levels out. When the traffic rate has decremented, it takes 16 time 
intervals with no BECNs before it starts to increase the traffic rate. Traffic increases by a rate of (Be 
+Bc)/16 when it starts to increase. 


With this background information in mind, you can move on to the specifics of configuring FRTS. Use 
the following process to configure Frame Relay traffic shaping: 


Step 1. Enable Frame Relay traffic shaping on the interface. Apply the frame-relay traffic- 
shaping command to the serial interface. 


Step 2. Create a Frame Relay map class for each VC that you want to apply shaping to. 
Multiple VCs can use the same map class. Use the frame-relay class class_name_1 [in | 
out] command under each VC. Use the global command map-class frame-relay 
class_name_1 to define the map class. When configuring the map class, the in/out options 
are optional. If it is omitted, the value applies to inbound and outbound traffic. 


Step 3. After you are in the map class configuration mode, configure the following options: 


frame-relay adaptive-shaping[becn | foresight]— You will be using BECN 
shaping; foresight is available if you are connecting to a Cisco |GX or BPX switch. 


frame-relay cir [in | out] bps— Set this speed to be the physical port speed of the 
circuit. 


frame-relay bc [in | out] bps— This is the amount of data sent per interval. A good 
number to use is 1/8 CIR of the remote circuit. ee 


frame-relay be out bps— This is the number of extra bits remaining from previous 
bursts that will be sent on the first interval. This should not exceed the port speed of 
the remote router. 


frame-relay mincir[in | out] bps— This is what the VC will throttle down to when it 
receives BECNs. Set this value to the actual CIR that the carrier provides to you. 


(Optional) frame-relay traffic-rate cir peak_speed— You can use this command as 
a shortcut for Steps 2 through 5. For CIR, use the value that the carrier has 


subscribed on the link. The peak speed should not exceed the physical link speed of 
the remote router. 


Step 4. (Optional) Apply any custom queuing or priority queuing to the map class, not to the 
interface. FIFO is the default queuing mechanism; apply custom queuing or priority queuing 
only if you have to. Use the following commands: 


frame-relay custom-queue-list list_number 
frame-relay priority-group list_number 


Practical Example: Configuring Frame Relay Traffic Shaping 
Figure 5-6 shows a Frame Relay point-to-point network. 


Figure 5-6. Frame Relay Traffic Shaping 
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In this model, you want to prevent the marlin router from flooding the glock router's 64-kbps PVC. 
At the same time, you want to shape traffic to the sig router. The port speed on the marlin and sig 
router is 1.544 Mbps, and it is 64 Kbps on the glock router. The PVC between the marlin and glock 
routers has a 32-kbps CIR set by the carrier. The PVC between the marlin router and the sig router 
is 512 kbps. 


Example 5-16 shows the first portion of the configuration for the marlin router. 
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Example 5-16 FRTS: marlin Router Configuration 


marlin(config) #int serial 0 


‘Enable FRTS 
marlin(config-if) #int s0O.1 
‘set map class 
marlin(config-—subif) #exit 
marlin(config) #int s0.2 
“set other map class 


marlin(config-subif) #*Z 


Now, you can define two map classes, one called 64kb and the other called tl. Example 5-17 
demonstrates the setting of a map classes. 


Example 5-17 Setting the Map Clas 


marlin(config) #map-class frame-relay 64kb 


| 


1 


marlin(config-map-class) #exit 
marlin(config) #map-class frame-relay tl 


| 
i 


| 
1 


marlin(config-map-class) # 


To verify your configuration, use the show traffic-shape command and add the DLCI number to 
enhance the show frame-relay pvc dici_number command. Example 5-18 lists the output of these 
commands, respectively. 


Example 5-18 show traffic-shape and show frame-relay pyc Command 
Output 


marlin#show traffic-shape 


Access Target Byte Sustain Excess Interval Increment Adap 
Le 
I/F List Rate Limit bits/int bits/int (ms) (bytes) Acti 
ve 
Se0 56000 7875 56000 56000 aS S13 BECN 


marlin# 
marlin# 
marlin#show frame pvc 120 


PVC Statistics for interface SerialO (Frame Relay DTE) 


DLCI = 120, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0.2 


input pkts 904 output pkts 3229 in bytes 94596 
out bytes 477394 dropped pkts 0 in FECN pkts 0 
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 
in DE pkts 0 out DE pkts 0 

out beast pkts 3204 out beast bytes 474980 


pve create time 19:25:28, last time pvc status changed 19:16:38 


pkts 3160 bytes 468932 pkts delayed 0 bytes delayed 0 
shaping inactive 
Serial0.2 dlci 120 is first come first serve default queueing 


Output queue 0/40, O drop, 0 dequeued 
marlin# 


With the aid of these commands, you can verify that you entered the configuration properly. In this 
example, shaping is listed as inactive because no BECNs have been received from the frame switch. 
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Lab 13: Configuring Frame Relay Networks and Controlling Frame 
Relay ARP—Part | 


Practical Scenario 


We began this chapter stating how prevalent Frame Relay had become in recent years. If you 
haven't worked on Frame Relay in the field, chances are good that you will. As common as Frame 
Relay networks are, one thing that isn't common is each network's individual design. Some 
networks strictly deploy subinterfaces in a point-to-point manner, whereas others might have 
more of a partially meshed network. This practice lab enables you to configure multiple types of 
Frame Relay networks. 


Lab Exercise 


Dr. Evil is in the process of implementing what he refers to as the "Evil Information 

Freeway" (EIF). The EIF is a Frame Relay network used to connect various factions of the evil 
empire. Because you are a henchman for the cruel Dr. Evil, you will have additional guidelines to 
abide by. Use the following parameters as your design guidelines: 


e Use the IP subnet 10.10.1.8/29 for the Frame Relay network between the Secret Volcano 
Lair (sv_lair), Scott's house (scotts_ house), and mini-me (mini_me). 

e Use the IP subnet of 192.168.1.4/30 for the Frame Relay link between sv_lair and 
starbucks 90210. 

e Use EIGRP as the routing protocol for IP. Use 666 as the autonomous system. 

e The frame switch will have a PVC from scotts_house to mini_me. Do not allow any traffic 
to pass on the PVC directly from scotts_house to mini_me. All traffic must go through the 
sv_lair first. 

e Per Dr. Evil, you can use subinterfaces only on the sv_lair router—or face the 
consequences. 


Lab Objectives 


e Configure the EIF network as depicted in Figure 5-7. Configure |P as denoted in the 
diagram. The LAN topology type is not important in this lab. 


Figure 5-7. EIF Frame Relay Network 
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e Use Frame Relay as the data link layer protocol on the WAN. 

e Prevent dynamic mapping of the PVC between scotts_house and mini_me. Any traceroutes 
preformed from mini_me to scotts_house, and vice versa, should go through the sv_lair 
router. 


Equipment Needed 


e Five Cisco routers, connected through V.35 back-to-back cables or in a similar manner. 
One router will serve as a frame switch and require four serial ports. 

e Four LAN segments, provided through hubs or switches. The LAN segments for mini_me 
and starbucks_ 90210 can be substituted with loopbacks. 


Physical Layout and Prestaging 


e Configure a frame switch to provide the PVCs, as listed in the diagram. See Chapter 1 if 
you need assistance in configuring a Frame Relay switch. Example 5-19 provides a sample 
frame switch configuration. 

e Connect the hubs and serial cables to the routers as shown in Figure 5-7. 

e Connect three Ethernet hubs to form three LAN segments, as shown in Figure 5-7. 
scotts_house can use either Token Ring or Ethernet for the purposes of this exercise. 


Example 5-19 Frame Relay Switch Configuration 
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hostname frame_switch 

! 

frame-relay switching 

! 

interface Ethernet0O 

no ip address 

shutdown 

! 

interface Serial0 

no ip address 

encapsulation frame-relay 

no fair-queue 

clockrate 148000 

frame-relay intf-type dce 
frame-relay route 121 interface 
frame-relay route 152 interface 
! 

interface Seriall 

no ip address 

encapsulation frame-relay 
clockrate 148000 

frame-relay intf-type dce 
frame-relay route 110 interface 
frame-relay route 120 interface 
frame-relay route 130 interface 
! 
interface Serial2 

no ip address 

shutdown 

! 
interface Serial3 

no ip address 

encapsulation frame-relay 
clockrate 64000 

frame-relay intf-type dce 


Seriall 
Serial5 


Serial5 
SerialO 
Serial3 


120 
151 


111 
121 
131 


frame-relay route 131 interface Seriall 130 


! 

interface Serial4 

no ip address 

shutdown 

! 
interface Serial5 

no ip address 
encapsulation frame-relay 
clockrate 64000 
frame-relay intf-type dce 


frame-relay route 111 interface Seriall 110 
frame-relay route 151 interface SerialO 152 
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Lab 13: Configuring Frame Relay Networks and Controlling Frame 
Relay ARP—Part Il 


Lab Walkthrough 


Attach the four routers in a back-to-back manner to the Frame Relay network cloud. Use V.35 
cables or CSU/DSUs with crossover cables to connect the routers to the Frame Relay switch. 
Create the four LANs by the use of switches or hubs/MAUs. 


When the physical connections are complete, assign IP addresses to all LAN interfaces, as 
depicted in Figure 5-7. Be sure that you can ping the router's local LAN interface before 


moving on. 


Begin with the sv_lair router, where you can use subinterfaces. Because the scotts_ house, 
mini_me, and sv_lair routers all have an interface on the same IP subnet, you must create a 
multipoint interface on sv_lair to accommodate them. There is an additional IP subnet between 
the sv_lair router and the starbucks_ 90210 router. For this subnet, you will create an additional 
point-to-point interface on the Serial 0 interface. With this in mind, you can begin the four-step 
process for configuring Frame Relay. 


First, you define Frame Relay encapsulation on the Serial 0 interface through the 

encapsulation frame-relay interface command. When the encapsulation is entered, you can 
define the subinterfaces. You need to configure one as a multipoint and one as a point-to-point 
subinterface, as previously mentioned. Example 5-20 demonstrates the configuration of Step 1 


on the sv_lair router. 


Example 5-20 Configuring Frame Encapsulation and Subinterfaces 


sv_lair(config) #int sO 

sv_lair(config-if) #encapsulation frame-relay 
sv_lair(config-if) #exit 

sv_lair (config) #int s0O.1 multipoint 
sv_lair(config-subif) #exit 

sv_lair (config) #int s0.2 point-to-point 
sv_lair(config-subif) #*2Z 
sv_lair# 


The next step in configuring Frame Relay is to set the LMI type. In this case, the LMI type is 
Cisco, and you are using LMI autosense, so there is no need to do any additional configuration 
for Step 2. This applies to all the routers in the network. 


Step 3 requires the specification of dynamic or static address mapping. The EIF will deploy both 
kinds of addressing. The sv_lair router uses a multipoint network on interface sO.1, which 
requires static mapping. You will need one frame-relay map statement per protocol per 
destination site. One frame-relay map statement will point to |1P address 10.10.1.10 on DLCl 
110, while the other will point to 1P address 10.10.1.11 on DLC! 120. Example 5-21 shows the 


configuration necessary to accomplish this. 


Example 5-21 Configuring the Multipoint I nterface 


sv_lair (config) #int s0.1 
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sv_lair(config-subif)#ip address 10.10.1.9 255.255.255.248 

sv_lair(config-—subif) #frame-relay map ip 10.10.1.10 110 broadcast 

sv_lair(config-subif) #frame-relay map ip 10.10.1.11 120 broadcast 

sv_lair(config-subif) #exit 

sv_lair (config) #int s0.2 

sv_lair(config-subif)#ip address 192.168.1.5 255.255.255.252 
( 
( 


sv_lair(config-subif) #frame-relay interface-dlci 130 


sv_lair(config—fr-dlci) #*Z 


To configure the point-to-point interface, sO.2, use Inverse ARP to resolve the network address. 
Therefore, the only configuration that you need to make is to add the interface-dlci command. 
The starbucks_ 90210 router requires only an encapsulation frame-relay statement and an 
interface-dlci 131 statement. 


Before you can address any protocol-specific issues, you must finish bringing up the Frame 
Relay network on all sides. Before trying to configure a routing protocol, you want to get the 
network to the point at which the router can ping all of its local WAN interfaces, as well as its 
local LAN interfaces. 


scotts_house is not allowed to use subinterfaces or the PVC to mini_me. As soon as both sides 
of the link between scotts_house and mini_me become active, a dynamic PVC is built by 
Inverse ARP. To prevent this from happening, you need to shut down the link and disable 
Inverse ARP. You also need to add two frame-relay map statements for IP. They will use the 
same DLCI but will point to two different IP addresses; basically, they will tell the router to 
forward all IP traffic out DLC] 111. Example 5-22 lists the configuration for the scotts_house 


router. 


Example 5-22 Configuration of scotts_ house 


scotts_house (config) #interface sO 
scotts_house(config-if) #encapsulation frame-relay 


Bese ee eae Seema eet renee re eye nvereeserD *“~ Disables Inverse-ARP 
SNe OTE (Sa oe Fe se ed eee | *~ Disables ARP 
scotts_house(config-if)#ip address 10.10.1.10 255.255.255.248 


scotts_house(config—-if) #frame-relay map ip 10.10.1.9 111 broadcast 
scotts_house (config—-if) #frame-relay map ip 10.10.1.11 111 broadcast 


The configuration of mini_me is similar. It requires two frame-relay map statements pointing 
at IP addresses 10.10.1.9 and 10.10.1.10 out DLC! 121. Example 5-23 demonstrates the 


configuration of mini_me. 


Example 5-23 Configuration of mini_me 


mini_me(config) #int sO 

mini_me (config—-if) #encapsulation frame-relay 
mini_me(config-if)#no frame-relay inverse-arp 
mini_me(config-if)#no arp frame-relay 

mini_me(config-if)#ip address 10.10.1.11 255.255.255.248 
mini_me (config—-if) #frame-relay map ip 10.10.1.10 121 broadcast 
mini_me (config—-if) #frame-relay map ip 10.10.1.9 121 broadcast 


Perform a show frame-relay map command on scotts_house and mini_me. Verify that there 
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is not a dynamic PVC on DLC! 151 or 150, as shown in Example 5-24. 


Example 5-24 Correct show frame-relay map Command Output with No 
ARP 


scotts_house#show frame-relay map 


broadcast, 
CISCO, status defined, active 


broadcast, 
CISCO, status defined, active 
scotts_house# 


If your frame-relay map statement looks like Example 5-25, you are using Inverse ARP. 


Example 5-25 Incorrect show frame-relay map, Using Inverse ARP 


scotts_house#show frame-relay map 


broadcast,, status defined, active 


broadcast,, status defined, active 


To test your frame-relay map statements, ping the local routers 10.10.1.9, 10.10.1.10, and 
10.10.1.11. 


Step 4 of the Frame Relay configuration process (the final step), involves addressing any 
routing protocol-specific issues. Start by configuring EIGRP on all routers, and use 666 as the 
Autonomous System ID. On the sv_lair and starbucks_ 90210 routers, you need to add two 
network statements under EIGRP. The other routers in the network need only the network 
10.0.0.0 and the no auto-summary statements. The configuration for sv_lair looks like 
Example 5-26. For further information on the EIGRP configuration, see Chapter 11, "Hybrid: 
Enhanced Interior Gateway Routing Protocol (EIGRP)," later in this book. 


Example 5-26 EI GRP Configuration for sv_lair and starbucks 90210 


router eigrp 666 
network 10.0.0.0 
network 192.168.1.0 


no auto-summary 
! 


The configuration might appear to be complete at this time—EIGRP neighbors are formed and 
routes are being exchanged. However, upon close examination of the routing tables of 
scotts_house and mini_me in Example 5-27, you'll find that sv_lair is not propagating its routes 
properly. The sv_lair is not forwarding scotts_house routes to mini_me, and it is not forwarding 
mini_me routes to scotts_house. But sv_lair is forwarding starbucks_90120 routes and its local 
routes to scotts_house and mini_me. 


Example 5-27 Examining the Routing Tables 
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scotts_house#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U - per-user static route, o —- ODR 
T -— traffic engineered route 


Gateway of last resort is not set 


10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks 


Cc 10.10.3.0/24 is directly connected, TokenRing0O 

Cc 10.10.1.8/29 is directly connected, Serial0O 
192.168.1.0/30 is subnetted, 1 subnets 

D 192.168.1.4 [90/2681856] via 10.10.1.9, 00:53:29, Serial0O 


scotts_house# 


Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 
D -— EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U —- per-user static route, o -— ODR 
T - traffic engineered route 


Gateway of last resort is not set 


10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks 


Q 


10.10.5.0/24 is directly connected, Ethernet0O 


Q 


10.10.1.8/29 is directly connected, Serial0d 
192.168.1.0/30 is subnetted, 1 subnets 


mini_me# 


<<<<<no 10.10.3.0 route>>>>>> 


sv_lair#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 
D -— EIGRP, EX - EIGRP external, O —- OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U - per-user static route, o - ODR 


Gateway of last resort is not set 


10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks 
10.10.2.0/24 is directly connected, Ethernet0O 


C 
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Cc 10.10.1.8/29 is directly connected, Serial0d.1 
192.168.1.0/30 is subnetted, 1 subnets 

Cc 192.168.1.4 is directly connected, Serial0.2 

sv_lair# 


<<<<<all routes present>>>>> 


If you haven't guessed it, the reason for this is because of split horizon. Remember, the rule: A 
route will not be forwarded back out the same interface or subinterface on which it was 
received. To resolve this issue, disable split horizon for EIGRP on the sv_lair router. This is 
accomplished by adding the following command under the sO.1 interface on sv_lair: 


sv_lair(config-subif)#no ip split-horizon eigrp 666 


Example 5-28 lists the routing table of scotts_ house after the change. Notice now that the 
10.10.5.0 route appears. 


Example 5-28 show ip route Command Output on the scotts_ house 
Router After Disabling Split Horizon 


scotts_house#show ip route 
<<<text omitted>>> 
Gateway of last resort is not set 


10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks 


D 10.10.2.0/24 [90/2195456] via 10.10.1.9, 00:00:09, Serial0O 
6: 10.10.3.0/24 is directly connected, TokenRing0O 
D 10.10.6.0/24 [90/2707456] via 10.10.1.9, 00:00:09, Serial0O 
Cc 10.10.1.8/29 is directly connected, Serial0d 

192.168.1.0/30 is subnetted, 1 subnets 
D 192.168.1.4 [90/2681856] via 10.10.1.9, 00:00:09, SerialO 


scotts_house# 


Another command that will help verify whether EIGRP is working properly is the show ip eigrp 
neighbor command. Performing this command on the sv_lair router, you can see three EIGRP 
neighbors, one for each remote site. Example 5-29 illustrates the output of this command. 


Chapter 11 discusses this command and EIGRP neighbors in greater detail. 


Example 5-29 show ip eigrp neighbor Command Output 


sv_lair#show ip eigrp neighbors 
IP-EIGRP neighbors for process 666 


H Address Interface Hold Uptime SRTT RTO Q Seg 
(sec) (ms) Cnt Num 

0) 192.168..1..6 Se0.2 128 00:04:34 32 200. 0 8 

2 iI 6 as er a Se0.1 179 00308219 33 200. ‘Q. “7 

i. © Wn Di Se0.1 161 00:08:54 24 200 O 7 


sv_lair# 


Example 5-30 lists the relevant portions of all router configurations for this lab. 


Example 5-30 Complete Configuration Listings 
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hostname sv_lair 
! 
interface Ethernet0O 
ip address 10.10.2.1 255.255.255.0 
media-type 10BaseT 
! 
<<<text omitted>>> 
! 
interface Serial0d 
no ip address 
encapsulation frame-relay 
no ip mroute-cache 
! 
interface Serial0O.1 multipoint 
ip address 10.10.1.9 255.255.255.248 
no ip split-horizon eigrp 666 
frame-relay map ip 10.10.1.10 110 broadcast 
frame-relay map ip 10.10.1.11 120 broadcast 
! 
interface Serial0.2 point-to-point 
ip address 192.168.1.5 255.255.255.252 
frame-relay interface-—dlci 130 
! 
<<<text omitted>>> 
! 
router eigrp 666 
network 10.0.0.0 
network 192.168.1.0 


no auto-summary 
! 


hostname scotts_house 

! 

ip subnet-—zero 

! 

interface Serial0O 

ip address 10.10.1.10 255.255.255.248 
no ip directed-broadcast 
encapsulation frame-relay 

no ip mroute-cache 

no arp frame-relay 

frame-relay map ip 10.10.1.9 111 broadcast 
frame-relay map ip 10.10.1.11 111 broadcast 
no frame-relay inverse-arp 

! 

interface TokenRingO 

ip address 10.10.3.3 255.255.255.0 

no ip directed-broadcast 

ring-speed 16 

! 

router eigrp 666 

network 10.0.0.0 


hostname mini_me 
' 


ip subnet-zero 
! 
interface Ethernet0O 
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ip address 10.10.5.5 255.255.255.0 

no ip directed-broadcast 

! 

interface Serial0d 

ip address 10.10.1.11 255.255.255.248 
no ip directed-broadcast 
encapsulation frame-relay 

no ip mroute-cache 

no arp frame-relay 

frame-relay map ip 10.10.1.9 121 broadcast 
frame-relay map ip 10.10.1.10 121 broadcast 
no frame-relay inverse-arp 

! 

interface Seriall 

no ip address 

no ip directed-broadcast 

shutdown 

! 

interface BRIO 

no ip address 

no ip directed-broadcast 

shutdown 
router eigrp 666 

network 10.0.0.0 


hostname mini_me 

! 

ip subnet-zero 

! 

interface Ethernet0O 

ip address 10.10.5.5 255.255.255.0 

no ip directed-broadcast 

! 

interface Serial0d 

ip address 10.10.1.11 255.255.255.248 

no ip directed-broadcast 

encapsulation frame-relay 

no ip mroute-cache 

no arp frame-relay 

frame-relay map ip 10.10.1.9 121 broadcast 
frame-relay map ip 10.10.1.10 121 broadcast 
no frame-relay inverse-arp 

! 
router eigrp 666 

network 10.0.0.0 


hostname starbucks_90210 
! 
interface Ethernet0 
ip address 10.10.6.6 255.255.255.0 
! 
interface Serial0O 
ip address 192.168.1.6 255.255.255.252 
encapsulation frame-relay 
frame-relay interface-—dlci 131 
! 
<<text omitted>>> 
! 
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router eigrp 666 
network 10.0.0.0 
network 192.168.1.0 
no auto-summary 
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Lab 14: Configuring Frame Relay Networks, Traffic Shaping, OSPF, & 
DLSw/LLC2—Part | 


Practical Scenario 


Most networks don't grow at an even, incremental basis. Some portions of the network might 
have faster newer links, while other parts of it could be older and slower. Oversubscription of links 
can be a common problem in Frame Relay networks. Traffic shaping helps address this problem. 
Enabling traffic shaping allows greater control over bursty traffic and the amount of data sent out 
an interface at any given time. This greatly helps the problem of high-speed links pushing too 
much data toward lower-speed links. This practice lab challenges you to configure traffic shaping 
in a multipoint Frame Relay network. 


Lab Exercise 


The J et Propulsion Laboratory (JPL) receives large graphic images from several telescopes. When 
the J PL receives these images, it immediately downloads them to Cape Canaveral in Florida and 
Houston, Texas. These images can be large at times and quickly saturate the links of the two 
NASA sites. To control these sudden bursts of large data, the J PL wants to deploy Frame Relay 
traffic shaping (FRTS). Use the following guidelines for your design and FRTS configuration: 


Use the IP network of 128.10.0.0 for all your addressing. 

Allow for only 14 host addresses on the J PL LAN. 

Use a 29-bit subnet mask on the WAN. 

Use 24-bit addressing on the remaining LANs. 

Use OSPF as the routing protocol for |1P. Assign the areas as depicted in Figure 5-8. 


Figure 5-8. NASA Frame Relay Network 
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e Configure Frame Relay traffic shaping using the following guidelines: The local port speed 
of JPL router is 1.544 Mbps. The CIR on the PVC to nasa_ houston is 32 kbps. The local 
port speed of nasa_houston is 64 kbps. Configure FRTS to optimize for the slowest link or 
the nasa_houston pvc. 


e (Optional): Configure DLSw lite between the two NASA routers' Ethernet segments, and 
use LLC2 as the encapsulation type. 


Lab Objectives 


e Configure the network as depicted in Figure 5-8. Configure IP by using the previously 
stated guidelines. 

e Use Frame Relay as data link layer protocol on the WAN. 

e Configure Frame Relay traffic shaping on the JPL router by using the previously stated 
guidelines. 

e Optional: Configure DLSw between the two NASA routers; use Frame Relay as the peer 
type. 


Equipment Needed 


e Four Cisco routers, connected through V.35 back-to-back cable or in a similar manner. 
One router will serve as a frame switch and require three serial ports. 
e Three LAN segments, provided through hubs or switches. 


Physical Layout and Prestaging 


e Configure a frame switch to provide the PVCs as listed in Figure 5-8. See Chapter 1 if you 
need assistance in configuring a Frame Relay switch. Example 5-31 provides a sample 
frame switch configuration. 

Connect the hubs and serial cables to the routers, as shown in Figure 5-8. 
e Connect three Ethernet hubs form three LAN segments, as shown in Figure 5-8. 


Example 5-31 Frame Relay Switch Configuration 


hostname frame_switch 

! 

frame-relay switching 

! 

<<<text omitted>>> 

! 

interface Serial0 

no ip address 

encapsulation frame-relay 

no fair-queue 

clockrate 148000 

frame-relay lmi-type cisco 

frame-relay intf-type dce 

frame-relay route 121 interface Seriall 120 
frame-relay route 165 interface Serial3 166 
! 

interface Seriall 

no ip address 

encapsulation frame-relay 
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clockrate 148000 

frame-relay lmi-type ansi 

frame-relay intf-type dce 

frame-relay route 120 interface SerialO 121 
frame-relay route 130 interface Serial3 131 
! 
<<<text omitted>>> 

! 

interface Serial3 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay lmi-type ansi 

frame-relay intf-type dce 

frame-relay route 131 interface Seriall 130 
frame-relay route 166 interface SerialO 165 


400 


Lab 14: Configuring Frame Relay Networks, Traffic Shaping, 
OSPF, & DLSw/LLC2—Part Il 


Lab Walkthrough 


Attach the three routers in a back-to-back manner to the frame switch. Use V.35 cables or 
CSU/DSUs with crossover cables to connect the routers to the frame switch. Create the three 
LANs by the use of switches or hubs/MAUs. 


This lab requires you to configure IP and OSPF. The order in which you will configure the 
network will be first the LANs for IP, second the WAN for IP, and finally OSPF. 


When the physical connections are complete, assign IP addresses to all LAN interfaces, as 
depicted in Figure 5-9. Be sure that you can ping the router's local LAN interface before 
moving on. 


Figure 5-9. 1P Addressing Map 
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Beginning with the JPL router, follow the four-step process for configuring Frame Relay. First, 
set the encapsulation type on the sO interface to frame-relay. The second step is to set the 
LMI type. In this case, it is ANSI. Therefore, you need to statically set it to ANSI with the 
frame-relay Imi-type ansi command. The third step involves statically mapping IP 
addresses to DLCls. The J PL router requires two frame-relay map statements, one pointing 
out DLC! 120 for IP address 128.10.10.5, and one pointing out DLCI 130 for IP address 
128.10.10.6. Example 5-32 shows the configuration for the JPL router up to this point. 
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Example 5-32 J PL Frame Relay Configuration 


interface Serial0 

no ip address 

encapsulation frame-relay 

no ip mroute-cache 

frame-relay lmi-type ansi 

! 

interface Serial0O.1 multipoint 

ip address 128.10.10.1 255.255.255.248 
frame-relay map ip 128.10.10.5 120 broadcast 
frame-relay map ip 128.10.10.6 130 broadcast 


Before you address any routing issues, as Step 4 of the Frame Relay configuration process 
indicates, you should configure the other two legs of the Frame Relay network. 


The nasa_cc and nasa_Houston configurations are similar. Each site will have one frame- 
relay map statement pointing at the jpl router and one pointing at the other nasa site. 
Example 5-33 lists the nasa_cc and nasa_houston Frame Relay configurations, respectively. 


Example 5-33 Frame Relay Configurations for the NASA Routers 


hostname nasa_cc 
interface Serial0 
no ip address 
no ip directed-broadcast 
encapsulation frame-relay 
no ip mroute-—cache 
frame-relay lmi-type cisco 
! 
interface Serial0O.1 multipoint 
ip address 128.10.10.5 255.255.255.248 
no ip directed-broadcast 
frame-relay map ip 128.10.10.1 121 broadcast 
frame-relay map ip 128.10.10.6 165 broadcast 


hostname nasa_houston 
! 
interface Serial0 
no ip address 
encapsulation frame-relay 
! 
interface Serial0.1 multipoint 
ip address 128.10.10.6 255.255.255.248 
frame-relay map ip 128.10.10.1 131 broadcast 


frame-relay map ip 128.10.10.5 166 broadcast 
! 


To test the configuration of the frame-relay map statements, ping the remote serial 
interface of the NASA routers from the jpl router. When you have connectivity to all your 
local devices, LAN and WAN, you can begin to configure a routing protocol. 


To learn more about configuring OSPF over Frame Relay, skip forward to Chapter 12, "Link- 
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State Protocols: Open Shortest Path First (OSPF)." This lab covers only minor configuration 
details. 


Starting with the jpl router, configure OSPF by adding two network statements, one for LAN 
in Area 100 and one for the WAN in Area 0. Be careful to use a precise wildcard mask of 
0.0.0.7 for the LAN and 0.0.0.15 for the WAN. To ensure that adjacencies are built, add a 
neighbor statement for each NASA site. Example 5-34 shows the OSPF configuration for the 


routers. 


Example 5-34 OSPF Configurations 


hostname jpl 

! 

router ospf 2001 

network 128.10.1.0 0.0.0.15 area 100 
network 128.10.10.0 0.0.0.7 area 0 
neighbor 128.10.10.5 priority 1 


neighbor 128.10.10.6 priority 1 
! 


hostname nasa_cc 

! 

router ospf 2001 

network 128.10.5.0 0.0.0.255 area 500 
network 128.10.10.0 0.0.0.15 area 0 
neighbor 128.10.10.6 priority 1 


neighbor 128.10.10.1 priority 1 
! 


hostname nasa_houston 

! 

router ospf 2001 

network 128.10.6.0 0.0.0.255 area 600 
network 128.10.10.0 0.0.0.7 area 0 
neighbor 128.10.10.5 priority 1 
neighbor 128.10.10.1 priority 1 


At this point, you should have full IP connectivity. Test this by pinging and viewing the OSPF 
neighbors with the show ip ospf neighbors command. Ensure that every router has two 
neighbors. If no adjacencies are formed, be sure to check the network statements and the 
IP addresses on the serial interface, along with the frame-relay map statements for 
configuration errors. 


The final portion of the lab requires applying FRTS to the serial interface of the J PL router. To 
accomplish this, you must first enable FRTS and then configure and apply a Frame Relay map 
class to frame-relay map statements. To enable FRTS, use the command frame-relay 
traffic-shaping under the Serial 0 interface. 


Next, you need to configure a map class for each PVC, depending on the values given. The 
key values that you need to set in each map class are as follows: 


adaptive shaping becn 
frame-relay cir 
frame-relay bc 
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frame-relay be 
frame-relay mincir 


You need a map class called 64k, and you need to primarily define the pvc to nasa_houston. 
The map class has adaptive shaping BECN response mode enabled. The cir is 1544000. bc is 
1/8 of the remote port speed, or 8000. The be field should be set not to exceed the other 
port speed of 64000. The be bit in this model is set to 64000; in the field, this value matches 
the QoS parameters that the WAN provider supplies. The mincir on this port is set to the 
actual CIR on the link. In this network, that is set at 32 kbps. Example 5-35 demonstrates 


the configuration needed for the 64k map class. 


Example 5-35 64k Frame Relay Map Class 


! 
map-class frame-relay 64k 
frame-relay cir 1544000 
frame-relay bc 8000 
frame-relay be 64000 
frame-relay mincir 32000 
frame-relay adaptive-shaping becn 


When the map class is defined, apply it to the PVC with the frame-relay class class_name 
command, specifically frame-relay class 64k. To verify that the map class is applied, 
perform a show frame-relay pvc command or the show frame-relay pvc 130 command 
for more details, as in Example 5-36. Ensure that the values highlighted are equal to the 


ones that you entered. 


Example 5-36 show frame-relay pvc 130 Command Output 


jpl#show frame-relay pvc 130 
PVC Statistics for interface Serial0O (Frame Relay DTE) 


DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0O.1 


input pkts 396 output pkts 391 in bytes 30732 
out bytes 30800 dropped pkts 0 in FECN pkts 0 
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 
in DE pkts 0 out DE pkts 0 

out bcast pkts 0 out bcast bytes 0 


pvc create time 03:55:53, last time pvc status changed 02:07:28 


pkts 225 bytes 17320 
shaping inactive 
Serial0.1 dlci 130 is first come first serve default queueing 


pkts delayed 0 bytes delayed 0 


Output queue 0/40, 0 drop, 0 dequeued 
jpl# 


The optional portion of this lab calls for creating a DLSw with LLC2 encapsulation between the 
two NASA routers, using Frame Relay encapsulation. For the local peer, you can simply use 
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the LAN address. You also need to create a remote peer, with Frame Relay encapsulation 
type. You will define a bridge group on Ethernet 0 and tie to this to the DLSw bridge group. 
Using the Frame Relay encapsulation type creates an LLC2 peer. To transport this type of 
traffic directly encapsulated in Frame Relay, you need to use the frame-relay map Ilc 
dici_number broadcast command. 


Example 5-37 lists the configuration for the nasa_cc and nasa_houston routers, respectively, 
highlighting the DLSw portions of the config. 


Example 5-37 DLSw over Frame Relay, NASA Configurations 


ip subnet-—zero 


interface Ethernet0O 
ip address 128.10.5.5 255.255.255.0 
no ip directed-broadcast 


interface Serial0d 

no ip address 

no ip directed-broadcast 

encapsulation frame-relay 

no ip mroute-cache 

frame-relay lmi-type cisco 

! 

interface Serial0.1 multipoint 

ip address 128.10.10.5 255.255.255.248 
no ip directed-broadcast 


frame-relay map ip 128.10.10.1 121 broadcast 
frame-relay map ip 128.10.10.6 165 broadcast 
! 
router ospf 2001 

network 128.10.5.0 0.0.0.255 area 500 
network 128.10.10.0 0.0.0.15 area 0 

neighbor 128.10.10.6 priority 1 

neighbor 128.10.10.1 priority 1 

! 

ip classless 
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interface Ethernet0O 
ip address 128.10.6.6 255.255.255.0 


! 
interface Serial0 

no ip address 

encapsulation frame-relay 

! 

interface Serial0O.1 multipoint 

ip address 128.10.10.6 255.255.255.248 


frame-relay map ip 128.10.10.1 131 broadcast 
frame-relay map ip 128.10.10.5 166 broadcast 
! 
router ospf 2001 

network 128.10.6.0 0.0.0.255 area 600 
network 128.10.10.0 0.0.0.7 area 0 

neighbor 128.10.10.5 priority 1 

neighbor 128.10.10.1 priority 1 

! 


no ip classless 
! 


Use the show disw peer command to verify the peer is in a "connect" state. For more 
information on DLSw and verifying and testing the DLSw portion, see Chapter 13, 
"Configuring Bridging and Data Link Switching Plus." 


For reference, Example 5-38 lists the configuration of the jpl router. 


Example 5-38 jpl Router Configuration 


hostname jpl 
! 
interface Ethernet0 
ip address 128.10.1.1 255.255.255.240 
media-type 10BaseT 
! 
interface Serial0 
no ip address 
encapsulation frame-relay 
no ip mroute-cache 
frame-relay traffic—-shaping 
frame-relay lmi-type ansi 
! 
interface Serial0O.1 multipoint 
ip address 128.10.10.1 255.255.255.248 
frame-relay class 64k 
frame-relay map ip 128.10.10.5 120 broadcast 
frame-relay map ip 128.10.10.6 130 broadcast 
! 
router ospf 2001 
network 128.10.1.0 0.0.0.15 area 100 
network 128.10.10.0 0.0.0.7 area 0 
neighbor 128.10.10.5 priority 1 
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neighbor 128.10.10.6 priority 1 
! 
ip classless 
! 
map-class frame-relay 64k 
frame-relay cir 1544000 
frame-relay bc 8000 
frame-relay be 64000 
frame-relay mincir 32000 
frame-relay adaptive-shaping becn 
! 
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Chapter 6. WAN Protocols and Technologies: Voice 
over X 


Authoring contribution by Eric Sandberg 


It's possible that the CCIE practical lab might include tasks involving the configuration of 
Cisco voice-capable routers for voice-over solutions (that is, voice over Frame Relay, Voice 
over IP and Voice over ATM). The purpose of this chapter is to give you enough information 
to successfully complete these configuration tasks. This chapter is not intended to be the "be 
all, end all" for information regarding telephony and voice-over solutions. Many good 
publications and Cisco classes are available to the general public that can fill that information 
void. | highly recommend Cisco Voice over Frame Relay, ATM, and IP and Voice over IP 
Fundamentals from Cisco Press, and any telephony or voice-related classes from a Cisco 
certified training partner. 


This chapter covers Cisco voice-over technology solutions and tells where they fit into the 
network, highlights voice-capable Cisco products, discusses configuration and 
implementation, and enumerates the benefits of a voice-over solution, including reduced long 
distance costs, more calls with less bandwidth, more and better enhanced services, and more 
efficient use of the Internet Protocol (IP). 


This chapter begins with a quick introduction to the basic elements of analog telephony. The 
overall objective is to teach engineers how to design, integrate, and configure voice over 
Frame Relay, ATM, and IP in the enterprise or managed network services using various Cisco 
1750, 2600, 3600, and 3810 multiservice access devices. 
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Introduction to Analog Telephony 


This section describes the telephone network with a focus on analog technology and includes 
the following topics: 


Telephone call components 
Telephone set components 
Telephone signaling 

Local loops 

Voice switches 

Trunks 

Trunk/line seizure signaling types 
Telephone call procedure 


Telephone Call Components 


Basic telephone call components consist of a telephone, a local loop, a voice switch (CO/ 
PBX), and trunks, as shown in Figure 6-1. Everyone is familiar with the telephone, but there 
are components within the telephone set that you might not be familiar with. The handset is 
the part of the phone that you hold in your hand to speak (transmit) and listen (receive) to a 
voice conversation. The switch hook is the lever that is pushed down while the handset is 
resting on the cradle (on-hook). When you lift the handset to place a call, the switch hook 
pops up and is in a state (off-hook) that allows current to flow through the phone. 


Figure 6-1. Basic Telephone Components 


409 


Telephone Components 


Two-Wire Telephone 
Local Company 
Loop Switch 


ail 


*Handset (receiver and transmitter) 
‘Switch hoak 

*Hybrid (two-to-four wire converter) 
*sSidetone 

«Dialer 

«Ringer 


In the handset are four wires split into two pairs, one for transmitting and one for receiving. 
In each phone there is a hybrid two-to-four-wire converter that acts as a communications 
bridge and provides the conversion between the four-wire handset and the two-wire local 
loop. Sidetone is another element that emanates from the hybrid, allowing a portion of 
speech to bleed over into the earpiece so that you can determine how loud you are talking. 
The dialer, either touch-tone or rotary, signals the telephone company that you are making a 
call. Pushing buttons on a touch-tone phone or spinning the dialer on a rotary phone sends a 
signal to the telephone company specifying the location from which you are calling. 


Finally, the last component of the telephone is the ringer. When someone is calling you, the 
telephone company sends voltage through the wires to your telephone, which triggers the 
ringer alerting you that there is an incoming call. 


Telephone Signaling 


When you use your phone to place or receive a call, you must communicate your intentions 
to your telephone company. Signaling does this. The two types of signaling discussed in this 
chapter are supervisory and address. Supervisory signaling is the means by which you and 
your telephone company notify each other of call status. The three different types of 
supervisory signaling are on-hook, off-hook, and ringing. 
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As discussed previously, allowing the handset to rest in the cradle (on-hook) opens the 
switch hook and prevents the current from flowing through your phone. Only the ringer is 
active when the handset is on-hook. On-hook signaling is illustrated in Figure 6-2. Lifting the 
handset off the cradle allows current to flow through the phone, alerting the phone company 
that you are requesting to make a call. The phone company, in turn, returns a dial tone to 
the phone to indicate that it is ready. Figure 6-3 illustrates off-hook signaling. When someone 
is calling you, the telephone sends voltage to the ringer. The phone company also sends a 
ringback tone to the caller, alerting the caller that it is sending ringing voltage to the 
recipient's phone. Ringing is illustrated in Figure 6-4. 


Figure 6-2. Supervisory Signaling—On-Hook 
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Figure 6-3. Supervisory Signaling—Off-Hook 
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Figure 6-4. Supervisory Signaling—Ringing 
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Address signaling can be one of two types, pulse or dual-tone multifrequency (DTMF). Rotary- 
dial phones, while somewhat outdated, are still in use today and use pulse address signaling. 
Each pulse consists of a make and a break. The make is the period during which the circuit is 
closed. The break segment is the time that the circuit is open. The cycle should correspond to 
the following ratio: 60 percent break, 40 percent make. A governor inside the dial controls 
the rate at which the digits are pulsed. Figure 6-5 illustrates the process for pulse address 


signaling. 


Figure 6-5. Address Signaling—Pulse 
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Touch-tone phones use DTMF signaling. When you look at the keypad, each row of keys is 

identified by a low-frequency tone, and each column is associated with a high-frequency 

tone. The combination of both tones notifies the phone company of the number you are 
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calling (hence the term DTMF). 


Figure 6-6 illustrates the combination of tones that you can generate for each button on the 
keypad. 


Figure 6-6. Address Signaling—Dual-Tone Multifrequency (DTMF) 
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Local Loops 


Your telephone is connected to the phone company by a local loop, sometimes referred to as 
"the last mile." The local loop contains an electrical communication path of two wires, one for 
transmitting and one for receiving voice signals (See Figure 6-7). The two-wire circuit is 
referred to as tip and ring. The ring is tied to the negative side of the battery at the phone 
company, and the tip is tied to the ground. Again, when you lift the handset off the cradle 
and go off-hook, the current flows down the wires and your phone company provides service 
to you. 


Figure 6-7. Local Loop 
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A loop is the physical pair of wires from the 
subscriber to the telephone company switch. 


Voice Switches 


The next piece of the telephony puzzle is the voice switch. The three types of switches 

discussed in this section are central office (CO) switches, intermediate switches, and private 

branch exchange (PBX) switches. A voice switch is a mechanical or electrical device that 
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directs your voice calls to the proper destination. Voice switches typically are located on your 
premises or at the phone company. The voice switch selectively establishes and releases 
connections between transmission facilities to provide dedicated paths for the exchange of 
messages between two calling parties. Paths are established before the information 
exchanges begin, and, until the callers terminate the sessions, these paths are maintained for 
the switch's exclusive use. 


Private phones are connected directly to a central office switch. When you place a telephone 
call to a central office switch, it forwards the call to one of the following: 


e Another central office switch 
e Anend user's phone (if it is connected to the same CO) 
e An intermediate switch 


The CO switch provides all the components to make your phone work—for example, battery, 
current detector, dial-tone generator, dial register, and ring generator. The battery is the 
source of power to both the circuit and the phone. The current detector monitors the status 
of the circuit by detecting whether the circuit is open or closed. The dial-tone generator 
generates a dial tone to acknowledge the request for service. When the PBX detects current 
flow on the interface, the dial register receives the dialed digit. The ring generator alerts the 
called party by sending a ring signal to the called party. 


Intermediate switches primarily act as a go between for the switch that forwards a call to 
other switches in the network, and they also connect trunks. 


PBX switches are used in the private sector. It would be inefficient at your place of business 
to run individual phone lines to the CO for each telephone in your office, for example. 
Instead, you would install a PBX at your office to provide connectivity between your phones 
and the CO through trunk lines. 


Figure 6-8 shows each of the different types of voice switches. 


Figure 6-8. Voice Switches—Central Office (CO), Intermediate, and 
Private Branch Exchange (PBX) Switches 
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Trunks 


The trunk's primary function is to provide the path between switches. Many different 
subscribers share a trunk, although only one uses it at any given time. There might be many 
trunks between two switches. A few of the more common trunk types are private trunk lines, 
central office trunks, foreign exchange trunks, and direct inward/direct outward dialing 
trunks, as shown in Figure 6-9. 


Figure 6-9. Figure 6-9 Trunks—Private, Central Office (CO), and 
Foreign Exchange 
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Generally, private-line trunks connect PBXs together, whereas CO trunks are direct 
connections between the local CO and a PBX. Foreign exchange trunks enable you to fool a 
switch into thinking that a remote telephone is directly attached to the switch. A foreign 
exchange office (FXO) and foreign exchange station (FXS) are needed to fool the switch into 
thinking that your telephone is directly connected to the switch. 


The FXO sits on the switch end of the connection. It plugs directly into the line side of the 
switch, so the switch thinks that the FXO interface is a telephone. The switch notifies the FXO 
of an incoming call by sending ringing voltage to the FXO. Likewise, the FXO answers a call 
by closing the loop to let current flow. When current is flowing, the FXO interface uses any 
current technology to transport the signal to the FXS. 


The FXS sits at the remote site and looks to the telephone like a switch. It provides the dial 
tone and battery to the telephone. The telephone thinks that it is the switch. 


Direct inward dial (DID) trunks are one-way trunks that allow you to dial into a PBX without 
operator intervention. The CO knows which calls to pass through a DID trunk because it 
associates a block of numbers with each DID trunk. 


Direct outward dial (DOD) trunks are also one-way trunks that allow you to connect directly 
to the CO. For example, if you want to place a call outside your company's network, you 
simply dial an access code such as 9, and the PBX forwards your call out to the CO. At that 
time, the CO provides a second dial tone and uses the remaining dialed digits to forward the 
call to the final destination. 


Figure 6-10 illustrates DID and DOD trunks. 
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Figure 6-10. Trunks-Direct |nward/ Direct Outward Dialing Trunks 
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Trunk Line Seizure Signaling Types 


This section covers trunk/line seizure signaling types, which are signaling standards that exist 
between lines and trunks in the telephone network. We focus on loop start signaling, ground 
start signaling, and E&M signaling. This information is critical to the successful configuration 
and implementation of your Cisco voice-over solution. 


NOTE 


E&M signaling commonly is referred to as ear and mouth or recEive and 
transMit, but its origin comes from the terms earth and magnet. Earth 
represents electrical ground, and magnet represents the electromagnet used to 
generate tones. 


Loop start signaling allows you or the telephone company to seize a line or trunk when a call 
is being initiated, as shown in Figure 6-11. It primarily is used on local loops rather than on 
trunks. Remember that when the line is in the idle state, it is said to be on-hook. If you lift 
the handset off the cradle, you cause the switch hook to go off-hook and close the loop. 
Current can now flow through the circuit, and the CO will detect the current and return a dial 
tone. Finally, if your telephone is ringing to alert you of an incoming call, the CO is applying 
AC ring voltage superimposed over the -48 VDC battery, causing the ring generator to notify 
you of a telephone call. When the PBX or telephone answers the call, the CO removes the 
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ring voltage. 


Figure 6-11. Loop Start Signaling 
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Loop start signaling is a poor signaling solution for high-volume trunks because it is possible 
to seize the trunk simultaneously from both ends. This problem is known as glare. Have you 
ever picked up the telephone to place an outbound call only to find the person you were 
calling already on the other end of the connection? Both parties seized the loop 
simultaneously, and you experienced glare. This might not be a significant problem in your 
home, but imagine the implications at your place of business, with several times the phone 
usage. Signaling methods that detect loop or trunk seizure at both ends solve the problem. 


Ground start signaling is a modified version of loop start signaling that corrects the 
probability of glare by providing current detection at both ends of the connection (see Figure 


6-12). Ground start signaling is preferable when high-volume trunks are involved. 


Figure 6-12. Ground Start Signaling 
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The following summarizes the ground start signaling process: 
1. When the line is idle or on-hook, the PBX monitors for ground on the tip lead. 
2. The battery from the CO appears on the ring lead. 
3. When you go-off hook, the PBX grounds the ring lead. 
4. The CO senses the ring ground and grounds the tip lead. 
5. The PBX detects the tip ground and closes the circuit to complete the call. 


E&M signaling supports tie-line- type facilities or signals between voice switches. Instead of 
superimposing both voice and signaling over the same wire, E&M uses separate leads for 
each. As you probably guessed, the M lead sends the signal and the E lead receives the 
signal. For example, if you want to place a call to someone at a remote office, your PBX 
routes this request over its signal leads for use of the trunk between the two sites. Your PBX 
makes this request by raising its M lead. The remote PBX detects the request when it detects 
current on its E lead. The remote PBX attaches a dial register to the trunk and your PBX. Your 
PBX sends the dialed digits, and the remote PBX raises its M lead to notify you that the call is 
complete. Five types of E&M signaling exist, as detailed in Table 6-1. 


Table 6-1. E&M Signaling 


PBX to Intermediate Device 


Type [Lead [On-hook [Off- hook 
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| M Ground Battery (-48 VDC) 
II M Open Battery (-48 VDC) 
HI M Ground Battery (-48 VDC) 
M 
M 


Intermediate Device to PIX 


Type [Lead [On-hook Off-hook 


| E Open Ground 

Open Ground 
t II E [Open Ground 
IV E Open Ground 


iv : [Open (Ground 


E&M Type | signaling (see Figure 6-13) is a two-wire signaling type common in North 
America. One wire is the E lead, and the other is the M lead. Approximately 75 percent of the 
PBXs in North America are E&M Type |. With the Type | interface, the tie line equipment 
generates the E signal to the PBX by grounding the E lead. The PBX detects the E signal by 
sensing the increase in current through a resistive load. Similarly, the PBX generates the M 
signal by sourcing a current to the tie line equipment, which detects it with a resistive load. 
The Type | interface requires that the PBX and tie line equipment share a common signaling 
ground reference. 


Figure 6-13. E&M Type | 
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E&M Type V (see Figure 6-14) is also a two-wire E&M signaling type most common outside 
North America. As with Type | signaling, Type V uses one wire for the E lead and one wire for 
the M lead. Type V requires a common ground between the PBX and the tie line equipment. 
This is provided by the signal ground leads. 


Figure 6-14. E&M Type V 
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E&M Type II is a four-wire interface (see Figure 6-15). Like Type | and V, Type II uses two 
wires for the E and M leads. Type II, however, uses the remaining two wires for signal ground 
and signal battery. These two wires also are used for the return path for the E and M leads. A 
Type II interface does not require a common ground; instead, each of the two signals has its 
own return path. 


Figure 6-15. E&M Type II 


423 


E&M Type Il Channel Bank or 
PBK Cisco Voice Equipment 


-48 VDC 


Four-wire, fully looped, nonsymmetrical 


E&M Type III is similar to Type II, but it uses the signal ground lead as the common ground 
(see Figure 6-16). The E lead operates similar to Type |. In this configuration, the PBX drops 
the M lead by grounding it rather than by opening a current loop. This is not a common 
signaling type. 


Figure 6-16. E&M Type III 
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E&M Type IV is symmetric and requires no common ground (see Figure 6-17). Each side 
closes a current loop to signal; the flow of current is detected by a resistive load to indicate 
the presence of a signal. E&M Type IV is not supported by Cisco. 


Figure 6-17. E&M Type lV 
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Trunk Supervision 


This section covers start protocols for trunk supervision. We will discuss wink start, delay 
start, and immediate start. Tie trunks have bidirectional supervisory signaling that allows 
either end to seize the trunk. One PBX seizes the trunk and expects an acknowledgment 
reply from the other end. The local end needs to differentiate between a return 
acknowledgment and a remote end request for service. 


The most common E&M trunk seizure signal type is wink start signaling. With this particular 
type of signaling, the office initiating the call seizes the line by going off-hook. The remote 
office does not immediately return an off-hook acknowledgment when it detects the line 
seizure of the calling office. Instead, the on-hook state is maintained until the receive digit 
register is attached. The called office toggles the off-hook lead for a specific amount of time 
(hence the term wink). When the calling office receives the wink, it forwards the digits to the 
remote office. The called office answers the telephone, and the PBX raises the M lead. Figure 
6-18 illustrates wink start signaling. 


Figure 6-18. Trunk Supervision Signaling: Wink Start 


426 


Trunk Supervision Signaling 
Wink Start 
Local PBX 


M-Lead —> 


i re 
ov Request Local end 


E-Lead for service hangs up 
-Lea 
— Wink 
tones 
. Digits forwarded 
ov g Called Remote end 
‘Register number terminated 
found answers 


With delay start signaling, the originating side goes off-hook and waits for about 200 ms; 
then it checks to see if the far end is on-hook. If the far end is on-hook, it then outputs dial 
digits. If the far end is off-hook, it waits until it goes on-hook and then outputs dial digits. 
The delay signal says, in effect, "Wait—I'm not ready to receive digits." Figure 6-19 shows 


the delay start signaling process. 


Figure 6-19. Trunk Supervision Signaling: Delay Start 
Trunk Supervision Signaling 
Delay Start 
Local PBA 


M-Lead  & 


-48V RO r 
OV Request Local End 


for Service Hangs Up 
E-Lead 
el 
PR | piats Forwarded [Xd 
Digits Forwarded | 
oe = Called Remote end 
Register found number terminated 
request answers 
acknowledgment 


Now, let's run through the process that takes place with immediate start signaling. With 
immediate start signaling, the calling office PBX seizes the line by going off-hook (see Figure 
6-20). Rather than waiting for the double acknowledgment from the remote office, the local 
PBX waits a predetermined amount of time (say, 150 ms) and then blindly forwards digits. 
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The remote PBX acknowledges the call only after the called party answers the telephone. 


Figure 6-20. Trunk Supervision Signaling: |mmediate Start 
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Two-to-Four-Wire Conversion and Echo 


Recall that the local loop is made up of two wires. When the local loop reaches the central 
office switch, it is changed to four wires with a two-to-four-wire hybrid converter. This is 
necessary for your signal to be transported across the trunks in the network. If there is a 
good impedance match between the lines, the hybrid is said to be balanced with little or no 
reflected energy. However, if there is an impedance mismatch or inadequate balance 
between the lines, a portion of the transmitted voice is reflected back toward the receiver 
side, resulting in echo. Some degree of echo is always present. When the magnitude or 
loudness of the echo becomes too high, it becomes a problem. 


Two common types of echo are talker echo, in which your voice reflects back to you (above 
and beyond side tone, which we discussed earlier) and you hear yourself twice. The other is 
listener echo, which gives the effect of hearing the speaker's voice twice. Echo is caused by 
delay. 


Two ways that you can attempt to solve this problem are echo suppression and echo 
cancellation. Echo suppression basically suppresses your voice on the return path. The echo 
suppressor determines which signals match you and which signals match the person you are 
talking to. If the echo suppressor determines that the echo is on the return path, it either 
attenuates or breaks the transmission path. However, if it is determined that both speech 
and echo are present at the same time from a combination of both parties, the echo cannot 
be attenuated without affecting the voice level. A more sophisticated method of dealing with 
echo is echo cancellation. Rather than breaking or attenuating the transmit path, as is the 
case with echo suppression, echo cancellation uses an echo canceller to build a mathematical 
model of the speech pattern and subtracts it from the transmit path. 


NOTE 


An echo canceller removes echo only from one end of the circuit. If echo exists 
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on both ends of the circuit, another echo canceller would need to be applied at 
the other end. 


To summarize, here are the basic elements involved in placing a telephone call. When your 
telephone is resting on the cradle (on-hook), the line is in an idle state and the telephone or 
PBX opens the two-wire loop. Lifting the handset off the cradle causes the switch hook to go 
off-hook, closing the loop and allowing current to flow through the circuit. The switch detects 
current and returns a dial tone. When a dial tone is received, you request a particular 
connection by dialing specific numbers. The switch signals the called party by sending ringing 
voltage. At the same time, the switch also sends an audible ring signal back to the caller 
notifying the caller that the call is in progress. The analog connection is complete when the 
called party lifts the handset, closing the loop and allowing current to flow through the circuit. 
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Digital Voice Technology 


Digital loop carrier technology was developed in the early 1970s with the idea of increasing 
transmission performance through digital technology. In addition to performance 
enhancements, digital technology is more reliable and easier to maintain than analog 
signaling. One of the key reasons for converting analog to digital is that digital signals are 
regenerated and do not accumulate noise in the same manner that analog signals do. 
Whereas analog signaling is represented as a continuous variable signal quantity such as 
voltage, digital signaling is represented as a sequence of binary digits indicating the presence 
of an electrical pulse (1) or lack thereof (0). 


Digitizing Analog Signals 


Analog-to-digital conversion is accomplished by a codec (coder, decoder). Codecs are used to 
convert voice frequency channels to 64-kbps digital signal level O (DSO) channels. The codec 
achieves the conversion by sampling, quantizing, and encoding the signal. 


Before delving further into the three steps that need to be performed for analog-to- digital 
conversion, let's take a minute to talk about Nyquist's Theorem (see Figure 6-21). As stated 


in the Nyquist Theorem: 
Figure 6-21. Digitizing Voice: Nyquist Theorem 
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A signal is sampled instantaneously at the transmitter at regular intervals and 
at a rate at least twice the highest frequency in the channel; then samples will 
contain sufficient information to allow an accurate reconstruction of the signal 
at the receiver. 


The highest frequency for a voice is 4000 Hz—thus, 8000 samples per second, or 1 every 125 
microseconds. Use the following formula to calculate the bit rate of digital voice: 


2x 4kHz x 8 bits per sample = 64,000 bps (64 kbps), or one DS-0 


Analog Signal to Digital Signal Conversion Process 
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Now that you have an understanding of Nyquist's Theorem, we will describe briefly the three 
steps of the conversion process (sampling, quantizing, and encoding), along with an optional 
fourth step, compression: 


1. Sampling — The analog signal is sampled at periodic intervals. The output of the 
sampling step is a pulse amplitude modulation (PAM) signal. 


2. Quantizing — The PAM signal is matched to a segmented scale. The purpose of this 
step is to measure the amplitude of the PAM signal and to assign an integer number 
that defines that amplitude. 


3. Encoding — The integer base-10 number is converted to an 8-bit binary number. The 
output is an 8-bit word in which each bit might be either a 1 (pulse) or a O (no pulse). 


4. Compression (optional) — Used to save bandwidth. Compression allows you to 
carry more voice calls over a single channel. 


The sections that follow examine these four steps in greater detail. 
Sampling and Quantization 


Quantization (see Figure 6-22) divides the range of amplitude values of an analog signal 
sample into a set of steps that are closest in value to the original analog signal. The voltage 
range is divided into 16 segments (0 to 7 positive and 0 to 7 negative). Beginning with 
segment 0, each segment has fewer steps than the previous, which reduces the noise-to- 
signal ratio. If there is a signal-to-noise ratio problem, it can be solved by converting PAM to 
PCM using a logarithmic scale. Linear sampling of an analog signal causes small amplitude 
signals to have a higher signal-to-noise ratio. u-law and A-law are two quantization methods 
that help solve this problem by allowing smaller step functions at lower amplitudes. Both 
compress the signal for transmission and then expand the signal back to its original form at 
the other end. The result is a more accurate value for smaller amplitude and uniform signal- 
to-noise quantization ratio across the input range. 


Figure 6-22. Quantization 
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Speech-Encoding Scheme 


The three types of speech-encoding schemes discussed here are waveform coders, vocoders, 
and hybrid coders. Waveform coders start with the analog waveform, taking 8000 samples 
per second, and then determine the most efficient way to code the analog signal for 
transmission. Pulse code modulation (PCM), adaptive differential pulse code modulation 


(ADPCM), H -law, and A-law are examples of waveform coders. Vocoding schemes use low 
bit rates but sound synthetic and are typically used in military applications. LPC, channel, and 
phase are examples of vocoders. Hybrid coders are part of what is called analysis by 
synthesis (AbS) coding. Because AbS continuously analyzes what a speech waveform should 
look like in the 5-ms future, hybrid coders are of a much higher quality than simple analysis 
and synthesis. Examples of hybrid coders are APC, SELP, and CELP. 


PCM (repeated 8000 times per second for a telephone voice channel service) is the most 
common method for converting analog to digital. When the PCM signal is transmitted to the 
receiver, it must be converted back to an analog signal. This is a two-step process requiring 
decoding and filtering. In the decoding process, the received 8-bit word is decoded to recover 
the number that defines the amplitude of that sample. This information is used to rebuild a 
PAM signal of the original amplitude. The PAM signal then is passed through a properly 
designed filter that reconstructs the original analog waveform from its digitally coded 
counterpart. 


Voice-Compression Techniques 


One of the benefits of compression, of course, is to reduce bandwidth, which, in turn, reduces 
the time and cost of transmission. Although not necessarily pertinent on high-bandwidth 
LANs, you can see where this could be beneficial in a voice-over solution across a WAN. 
However, compression can result in distortion and delay otherwise known as echo. 
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The two types of voice-compression techniques discussed here are waveform algorithms and 
source algorithms. Adaptive differential pulse code modulation (ADPCM) is an example of 
waveform compression. ADPCM is a way of encoding analog voice signals into digital signals 
by adaptively predicting future encodings by looking at the immediate past. The adaptive part 


reduces the number of bits required to encode voice signals. The ITU standards for waveform 
compression are as follows: 


G.721 rate—32 kbps = (2 x 4 kHz) x 4 bits/sample 
G.723 rate—24 kbps = (2 x 4 kHz) x 3 bits/sample 


G.726 rate—16 kbps = (2 x 4 kHz) x 2 bits/sample 


NOTE 


Remember that the standard pulse code modulation (PCM/G.711) requires 64 
kbps. 


Two examples of source compression are Low Delay Code Excited Linear Predictive (LD CELP) 
and Conjugate Structure Algebraic Code Excited Linear Predictive (CS-ACELP). 


CELP is a hybrid coding scheme that delivers high-quality voice at low bit rates, is processor- 
intensive, and uses DSPs. 


CELP transforms analog voice signals as follows: 
1. Input to the coder is converted from 8-bit PCM to 16-bit linear PCM sample. 
2. A codebook uses feedback to continuously learn and predict the voice waveform. 
3. The coder is excited by a white noise generator. 


4. The mathematical result is sent to the far-end decoder for synthesis and generation of 
the voice waveform. 


The ITU standards for CELP are listed here: 


e G.728 rate = 16 kbps 
e G.729 rate = 8 kbps 


G.729a is a variant that uses 8 kbps, is less processor-intensive, and allows two voice 
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channels encoded per DSP. 


G.729 is the CS-ACELP that Cisco uses for high-quality 8 kbps in all voice-capable 
routers. However, it does have a limitation of one voice channel on a single DSP. 
G.729a, although not quite as high quality, is less processor-intensive and can 
support two voice channels on a single DSP. 


In summary, here is a quick recap of the compression techniques discussed: 


PCM— The amplitude of voice signal is sampled and quantized 8000 times per 
second. Each sample then is represented by one octet (8 bits) and is transmitted. 


Either A-law or H -law is used for sampling to reduce the signal-to-noise ratio. PCM is 
technically a codec, not a compression technique. 


ADPCM— In this method, the difference between the current sample and its predicted 
value based on the past sample is used. This method reduces the bandwidth 
requirement at the cost of quality of the signal. The sample might be represented by 
2, 3, 4, or 5 bits. 


CELP— In all these algorithms, an excitation value and a set of linear predictive filters 
are transmitted. The filter settings transmission are less frequent than excitation 
values and are sent on an as-needed basis. 


Figure 6-23 illustrates the various compression technologies, the amount of bandwidth 
required to set up and maintain a call with the compression, and the different categories of 
voice quality. 


Figure 6-23. Cisco's Voice-Compression Technologies 
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Digital Speech Interpolation 


Similar to statistical multiplexing, digital speech interpolation (DSI) multiplexes bandwidth 
among a larger number of users than there are circuits. DSI uses voice activity detection and 
silence suppression to allocate the silent periods in human speech and put them to active 
use. Remember that 50 percent of a voice conversation is silence. 


Mean Opinion Scoring (MOS) is a subjective method of grading telephone voice quality. The 
MOS is a statistical measurement of voice quality derived from a large number of subscribers 
judging the quality of the connection. The grading scale is 1 to 5, with 5 being excellent and 
1 being unsatisfactory. 


Channel Signaling Types and Frame Formats 


Digital service level 0 (DS-0) is the smallest unit of transmission in the hierarchy. It is a 64- 
kbps circuit. A DS-0 channel can carry one digital PCM voice call. A total of 24 DS-Os can be 
multiplexed together to form the next level, called a DS1. A digital service level 1 (DS-1) is a 
1.544-Mbps circuit. A DS1 carries 24 8-bit byte DS-Os at 1.544 Mbps. A DS-1 frame is 193 
bits long, containing 8 bits from each of the 24 DS-Os, plus 1 framing bit. The two major 
framing formats for Tl are D4 and Extended Superframe Format (ESF). D4 specifies 12 
frames in sequence as a superframe. A superframe uses A- and B-bit signaling or robbed- bit 
signaling in frames 6 and 12 for control signaling. These robbed bits are the least significant 
bit from an 8-bit word. 


More prevalent in private and public networks is the ESF format. ESF specifies 24 frames in 
sequence with framing and a cyclical redundancy check (CRC). ESF also uses robbed- bit 
signaling in frames 6, 12, 18, and 24, also Known as ABCD signaling. Like D4, these are 
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the least significant bits in the frames. Both formats retain the basic frame structure of 192 
data bits followed by 1 framing bit. The 193rd bit of each DS1 frame is used for 
synchronization. The European equivalent to T1/DS-1 is the El. The El is composed of 32 64- 
kbps channels that make up a transmission rate of 2.048 Mbps. Thirty of these channels are 
used for voice and data. 


NOTE 


The terms DS-1 and T1 are often confused. The T1 actually identifies the 
physical attributes of a 1.544-Mbps transmission medium. 


Channel 0 is used for framing, and channel 16 is used for channel signaling. In El frame 
format, 32 time slots make up a frame. Sixteen E1 frames make up a multiframe. 


Two different digital channel signaling types are Channel Associated Signaling (CAS) and 
Common Channel Signaling (CCS). CAS (see Figure 6-24) is signaling in which the signals 


necessary to switch a given circuit are transmitted through the circuit itself or through a 
signaling channel permanently associated with it. 


Figure 6-24. Digital Channel Signaling Types—CAS 
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CCS (see Figure 6-25) is signaling in which one channel in each link is used for signaling to 


control, account for, and manage traffic on all channels of the link. The channel used for CCS 
does not carry user data. 


Figure 6-25. Common Channel Signaling Types—CCS 
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Cisco Voice Products 


This section lists each Cisco voice-capable router and gives a brief description of its 
multiservice voice/data integration. We will cover the Cisco 1750, Cisco MC3810, Cisco 2600, 
Cisco 3600, and Cisco 7200 series routers. 


The Voice Network Modules for the Cisco 2600 and 3600 series support up to two voice 
interface cards that come in three different types. Each of these provides a slightly different 
interface for connecting to different types of equipment: 


e Foreign exchange office (FXO)— The FXO interface is a connector that allows an 
analog connection to be directed at the central office of the PSTN. This interface is of 
value for an off-premises extension application. This is the only voice interface card 
that will be approved to connect to off-premises lines. This interface might be used to 
provide backup over the PSTN or for Centrex-type operations. 


e Foreign exchange station (FXS)— The FXS interface is a connector that allows 
connection for normal basic telephone service phones, fax machines, key sets and 
PBXs; it provides ring voltage, dial tone, and so forth. It is used where phones are 
connecting directly to the router. 


e Ear and mouth (E&M)— The E&MM interface is a connector that allows connection for 
PBX trunk line (tie lines). It is a signaling technique for two- and four-wire telephone 
and trunk interfaces. This has been a popular interface for PBX extension-type 
applications. 


Cisco 1750 


The Cisco 1750 is a multiservice access router that uses Cisco |OS with QOS to provide voice/ 
fax and data integration. The Cisco 1750 supports the same WAN interface modules as the 
Cisco 1600, 1720, 2600, and 3600 routers. The Cisco 1750 also supports the same analog 
voice interface cards and voice over IP technology as the Cisco 2600 and 3600 routers. The 
voice interface cards include support for FXO, FXS, and E&M. 


Cisco 2600 


The Voice over IP feature enables the Cisco 2600 and 3600 to carry voice traffic 
simultaneously with data traffic over an IP network. Voice over IP is primarily a software 
feature supporting both voice and fax calls. Support for the ISDN BRI signaling type allows a 
2600 or 3600 to provide voice access connectivity to either an ISDN telephone network or a 
digital interface on a PBX/key system. The voice or data also crosses an IP network to which 
the router connects. 


Cisco 3600 


The Cisco 3600 supports Voice over IP, Voice over Frame Relay, and Voice over ATM (3640 
and 3660), which allows voice traffic to be transported over existing WAN infrastructures, 
including ISDN, leased lines, ATM, and Frame Relay. Additional features include support for 
fax relay and interoperability with other H.323 applications. 
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Cisco MC3810 


The key benefits of the MC3810 are voice and data integration. The MC3810 integrates LAN, 
synchronous data, legacy, voice, video, and fax traffic for transport over a public or private 
Frame Relay, ATM, TDM, and VoIP networks. The MC3810 optimizes network bandwidth by 
multiplexing voice and data on the same physical interface. The analog model of the MC3810 
has 6 voice ports, and the digital model houses a single digital voice access port (T1/E1) of 
up to 24 compressed voice channels. 


Cisco 7200 


The Cisco 7200 series provides both enterprise and service provider customers with a choice 
of either a four- or a six-slot chassis. The 7200 provides service providers with the foundation 
for managed router and managed network services with multiservice for data, voice, and 
video integration. The 7200 extends the multiservice capabilities to support VoIP services, as 
well as voice- processing extensions such as voice compression and PBX signaling. The 7200 
supports multiservice aggregation of lower-end or branch CPE applications for a cost-effective 
end-to-end solution. 


Comparison of Cisco Voice-Capable Routers 


In summary, the Cisco voice-capable routers that offer a high level of multiservice voice/data 
integration include the following: 


e The Cisco 1750 offers voice/fax/data integration. 

e The Cisco MC3810 provides an end-to-end multiservice solution for VoFR, VoATM, and 
VoIP. 

e The Cisco 2600, 3600, and 7200 support VoFR, VoIP, and VoATM. 
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Lab 15: Configuring Voice over Frame, Voice over IP, and Voice over 
ATM 


Practical Scenario 


Voice over X is a growing technology. We strongly suggest modeling any voice networks in a lab 
scenario before deploying them in production. This will allow you to have a strong understanding 
of the configuration required before it is in a production environment. Essentially, we are 
configuring toll bypass. Toll bypass involves placing a voice call over the IP network so that toll 
charges are not incurred. All the lab modules that follow are configuring toll bypass in one form or 
another. They represent the first step in moving toward a multiservice converged internetwork. 


Lab Exercise 


This lab is treated in modules that allow you to model the following: 


e Voice over Frame 
e Voice over IP 
e Voice over ATM 


Lab Objectives 


e Inthe lab exercises, you configure toll bypass using the following methods: 
e Using Voice over Frame Relay. Configure the Frame Relay network in Figure 6-26 so that 


voice calls can be placed from one router to the next. 


Figure 6-26. Voice over Frame Relay Lab 
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e Using Voice over IP across a Frame Relay network. Configure the network in Figure 6-27 


so that voice calls can be placed from one router to the next. 


Figure 6-27. Voice over Frame Relay Lab 
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e Using a point-to-point voice over ATM application and, as an optional exercise, a private 
line automatic ring down (PLAR) application. Configure the network in Figure 6-28 so that 
voice calls can be placed from one router to the next. 


Figure 6-28. Voice over Frame Relay Lab 
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The lab is divided into three portions, Voice over Frame, Voice over IP, and Voice over ATM. The 
Voice over Frame and Voice over IP configurations build upon each other. The walkthrough for 
each lab is presented. 


Equipment Needed 
442 


Two Cisco voice-capable routers, each with a foreign exchange station (FXS) interface 
where you will connect your analog phone sets. We used Cisco 3600s in our labs, but the 
Cisco 2600s will work nicely as well. 

A Cisco router such as a Cisco 2600 series (Something with two serial interfaces) that you 
will use as your frame relay switch. 

Two analog phone sets. 

For the ATM portion of the lab, two Cisco voice-capable routers, each with an FXS interface 
where you will connect your analog phone sets. Each should have at least one ATM 
interface for the point-to-point connection. 
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Lab 15a: Configuring Voice over Frame Relay—Part | 


Physical Layout and Prestaging 


e Connect one of the Cisco voice-capable routers to the Serial 1/2 interface on the Cisco 
2600 series router (Frame Relay switch), as shown in Figure 6-26. 

e Connect the other Cisco voice-capable router to the Serial 1/3 interface on the Cisco 
2600 series router (Frame Relay switch), as shown in Figure 6-26. 

e Connect an analog phone set to each of the FXS interfaces on the Cisco voice- capable 
routers, as shown in Figure 6-26. 


Configuring and Verifying Voice Ports 


Configuring the ports on the router for the telephone headsets can be configured in the lab or 
as part of the prestaging. Example 6-1 shows the configuration for voice ports and for the 
Frame Relay switch that will be used in both the VoIP and VoFR labs. 


Example 6-1 Configuring the Voice Ports and Frame Relay Switc 


hostname frame-switch 


frame-relay switching 


<<<text omitted>>> 


interface Seriall1/0 


no fair-queue 
clockrate 64000 
frame-relay intf-type dce 


interface Seriall1/1 
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<<<text omitted>>> 
d 


J 
t=] 


frame-switch# 


hostname vofrl 

! 

<<<text omitted>>> 

! 

voice-port 3/0/0 

timeouts call-disconnect 0 
! 

voice-port 3/0/1 

timeouts call-disconnect 0 
! 

voice-port 3/1/0 

timeouts call-disconnect 0 
! 

voice-port 3/1/1 

timeouts call-disconnect 0 


—_ 


<<<text omitted>>> 
! 


<<<text omitted>>> 
! 


—- 
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! 
<<<text omitted>>> 


2! 
end 


vofrl# 
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Lab 15a: Configuring Voice over Frame Relay—Part Il 
Lab Walkthrough 


POTS peers enable incoming calls to be received by a particular telephony device. To 
configure a POTS peer, you need to uniquely identify the peer (by assigning it a unique tag 
number), define its telephone number(s), and associate it with a voice port through which 
calls will be established. In this example, you are using a four-digit dialing plan. 


To configure a POTS dial peer, use the commands in Table 6-2 beginning in global 
configuration mode. 


Table 6-2. Steps for Configuring POTS Dial Peers 


| Step | Command | Purpose 


“tia Router# configure Enters global configuration mode. 
terminal 


ai Router(config)# dial-peer j|Enters dial peer configuration mode and defines 
voice number pots a local dial peer that will connect to the POTS 
network. 


The number argument is one or more digits 
identifying the dial peer. Valid entries are from 1 
to 2147483647. 


The pots keyword indicates a peer using basic 
telephone service. 


Configures the destination pattern of the dial 


= destination-pattern string {Peer so that the system can reconcile dialed 
[T] digits with a telephone number. 


Step |Router(config-dialpeer)# 


The string argument is a series of digits that 
specify the E.164 or private dialing plan phone 
number. Valid entries are the numerals 0 
through 9 and the letters A through D. The plus 
symbol (+) is not valid. You can enter the 
following special characters: 


e The star character (*) that appears on 
standard touchtone dial pads can be in 
any dial string but not as a leading 
character (for example, *650). 

e The period (.) acts as a wildcard 
character. 

e The comma (,) can be used only in 
prefixes and inserts a 1-second pause. 


447 


When the timer (T) character is included at the 
end of the destination pattern, the system 
collects dialed digits as they are entered until the 
interdigit timer expires (10 seconds, by default) 
or the user dials the termination of the end-of- 
dialing key (default is #). 


To configure a VoFR dial peer, you need to uniquely identify the peer (by assigning it a 
unique tag number) and define the outgoing serial port number and the virtual circuit 
number. 


Depending on your dial plan configuration, you might need to consider how to configure voice 
networks with variable-length dial plans, number expansion, excess digit playout, forward 
digits, and default voice routes, or use hunt groups with dial peer preferences. 


If you will be sending switched calls over the Frame Relay network, you must configure the 
VoFR dial peers to specifically support switched calls. 


To configure a VoFR dial peer to support switched calls, use the commands shown in Table 6- 
3 beginning in global configuration mode. 


Table 6-3. Steps for Configuring VoFR Dial Peers to Support Switched 


Calls 
Step Command Purpose 
Step |Router(config)# dial-peer voice [Defines a VoFR dial peer and enters dial 
1 number vofr peer configuration mode. All subsequent 


commands that you enter in dial peer 
voice mode before you exit will apply to 
this dial peer. 


The number value tag identifies the dial 
peer and must be unique on the router. 
Do not duplicate a specific tag number. 


Step |Router(config-dial- peer) # Configures the dial peer 

2 destination-pattern string destination pattern. The same 
restrictions for the string listed in 
the POTS dial-peer configuration 
apply to the VoFR destination 
pattern. 

Step |Router(config-dial- peer) # Configures the Frame Relay 

3 session target interface dlci session target for the dial peer. 


[cid] 


The physical serial interface, Serial 1/0, is configured to support Frame Relay encapsulation. 
You also will notice that Frame Relay traffic shaping is configured. Enabling FRTS on apie 


interface enables both traffic shaping and per-VC queuing on all the PVCs and SVCs on the 
interface. Traffic shaping enables the router to control the output rate of the circuit and react 
to congestion notification information, if also configured. 


The logical interface Serial 1/0.1 is configured as a basic point-to-point subinterface. Again, 
notice the two additional configuration parameters on this interface: class voice and vofr 
cisco. To associate a map class with a specified data-link connection identifier (DLCI), use the 
class virtual circuit configuration command. To remove the association between the DLCI 

and the map class, use the no form of this command. On the Cisco 2600, 3600, and 7200 
series routers, entering the vofr cisco command is the only method for configuring Cisco 
proprietary voice encapsulation. You must then configure a map class to enable voice traffic 
on the PVCs. 


The map-class frame-relay vofr is just defining a map class named vofr. To specify how 
much bandwidth should be reserved for voice traffic on a specific DLCI, use the frame-relay 
voice bandwidth command. To release the bandwidth previously reserved for voice traffic, 
use the no form of this command. 


Example 6-2 defines a Frame Relay map class named voice. 


Example 6-2 Defining a Frame Relay Map Class 


map-class frame-relay voice 
frame-relay cir 768000 
frame-relay bc 1000 
frame-relay mincir 120000 
no frame-relay adaptive-shaping 
frame-relay fair-—queue 
frame-relay voice bandwidth 78000 
frame-relay fragment 1500 


To specify the incoming or outgoing committed information rate (CIR) for a Frame Relay 
virtual circuit, use the frame-relay cir map class configuration command. To reset the CIR 
to the default, use the no form of this command. 


To specify the incoming or outgoing committed burst size (Bc) in bits for a Frame Relay 
virtual circuit, use the frame-relay bc map class configuration command. In this example, 
1000 bits is used. To reset the committed burst size to the default, use the no form of this 
command. 


To specify the minimum acceptable incoming or outgoing CIR in bits per second for a Frame 
Relay virtual circuit, use the frame-relay mincir map class configuration command. In this 
example, 120000 bits is used. To reset the minimum acceptable CIR to the default, use the 
no form of this command. 


To select the type of backward notification that you want to use, use the frame-relay 
adaptive-shaping map class configuration command. To disable backward notification, use 
the no form of the command. 


To enable weighted fair queuing for one or more Frame Relay PVCs, use the frame-relay 
fair-queue map class configuration command in conjunction with the map-class frame- 
relay command. To disable weighted fair queuing for a Frame Relay map class, use the no 


form of this command. 
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To specify how much bandwidth should be reserved for voice traffic on a specific DLCI, use 
the frame-relay voice bandwidth command. To release the bandwidth previously reserved 
for voice traffic, use the no form of this command. 


To enable fragmentation of Frame Relay frames for a Frame Relay map class, use the frame- 
relay fragment map class configuration command. To disable Frame Relay fragmentation, 
use the no form of this command. Fragment size specifies the number of payload bytes from 
the original Frame Relay frame that will go into each fragment. This number excludes the 
Frame Relay header of the original frame. All the fragments of a Frame Relay frame except 
the last will have a payload size equal to fragment_size; the last fragment will have a 
payload less than or equal to fragment_size. Valid values are from 16 to 1600 bytes; the 
default is 53. 


In Example 6-3, the configuration parameters on vofr2 are much the same as those in vofr1, 


with the exception of the dial peers. The destination patterns are reversed and the dlci 
information in the session target has been changed to point to the correct dlci. 


Example 6-3 Configuring the Voice Ports on vofr2 


Current configuration: 

! 

version 12.0 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 


! 
! 


enable password cisco 
! 
ip subnet-zero 


no ip domain-lookup 
! 


! 
! 
! 


voice-port 3/0/0 

timeouts call-disconnect 0 
1 

voice-port 3/0/1 

timeouts call-disconnect 0 
i} 
voice-port 3/1/0 

timeouts call-disconnect 0 
1 


voice-port 3/1/1 
timeouts call-disconnect 0 
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! 

! 

interface Ethernet0/0 

no ip address 

no ip directed-broadcast 
shutdown 

! 

interface TokenRing0O/0 

no ip address 

no ip directed-broadcast 
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interface Seriall/1 

no ip address 

no ip directed-broadcast 
shutdown 

! 
interface Seriall/2 

no ip address 

no ip directed-broadcast 
shutdown 

! 

interface Seriall/3 

no ip address 

no ip directed-broadcast 
shutdown 

! 

interface FastEthernet2/0 
no ip address 

no ip directed-broadcast 
shutdown 

! 

router igrp 1 

network 150.150.0.0 

! 

ip classless 


no ip http server 
! 
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line con 0 

password cisco 
transport input none 
line aux 0 

password cisco 
line vty 0 4 

password cisco 

login 

! 


end 


VoEr2 + 


Now that both router configurations are complete, pick up the phone set on vofr1 and dial the 
digits 2222. If your configurations are correct and your routers are physically connected as 
described earlier, you should be able to complete a successful call. Hang up the phone set on 
vofrl and try placing a call from vofr2 by dialing 1111. 
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Lab 15b: Configuring Voice over |P—Part | 
Equipment Needed 


For the voice over IP lab, you need the following equipment: 


e Two Cisco voice-capable routers, each with an FXS interface where you will connect 
your analog phone sets. We used Cisco 3600s in our labs, but the Cisco 2600s will 
work nicely as well. 

e A low-end Cisco router, such as a Cisco 2500 series (something with two serial 
interfaces), that you will use as your Frame Relay switch. 

e Two analog phone sets. 


Physical Layout and Prestaging 


e Connect one of the Cisco voice-capable routers to the Serial 1/2 interface on the Cisco 
2600 series router (Frame switch), as shown in Figure 6-27. 

e Connect the other Cisco voice-capable router to the Serial 1/3 interface on the Cisco 
2600 series router (Frame switch), as shown in Figure 6-27. 


e Connect an analog phone set to each of the FXS interfaces on the Cisco voice- capable 
routers, as shown in Figure 6-27. 
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Lab 15b: Configuring Voice over IP—Part Il 
Lab Walkthrough 


Example 6-4 shows the configurations that you will use on each of these routers to 
accomplish your Voice over IP lab. The configuration of the voice ports, dial peers, and QOS 
mechanisms are discussed. For the purpose of this lab, the Cisco voice-capable routers have 
host names of voip1 and voip2. 


Example 6-4 Configuring Voice over IP on voip1 


Current. configuration: 

! 

version 12.1 

service timestamps debug uptime 
service timestamps log uptime 


no service password-encryption 
! 
! 


enable password cisco 


! 
! 
! 
! 
! 
! 


ces 1/0 

! 

ip subnet-zero 

no ip domain-lookup 
! 


lane client flush 
! 


! 
! 
! 
! 


controller T1 1/0 

i} 

1 

! 

interface FastEthernet0/0 
no ip address 

shutdown 

duplex auto 

speed auto 

1 
interface FastEthernet0/1 
no ip address 

shutdown 

duplex auto 


speed auto 
1 
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interface ATM1/0 


interface Serial2/1 
no ip address 
shutdown 


interface Serial2/2 
no ip address 
shutdown 


interface Serial2/3 
no ip address 
shutdown 


router rip 
network 150.150.0.0 


ip classless 
no ip http server 


voice-port 3/0/0 


voice-port 3/0/1 


voice-port 3/1/0 


voice-port 3/1/1 
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: 


1 
line con 0 
password cisco 
transport input none 
line aux 0 
password cisco 
line vty 0 4 
password cisco 
login 
i} 


end 


The configurations for the VoIP lab and VoFR lab are similar, with a few exceptions. These 
exceptions include the VoIP dial peer, the IP precedence associated with the VoIP dial peer, 
the Frame Relay IP RTP header compression on the Serial subinterface, and the Frame Relay 
IP RTP priority defined in the map class. 


Let's start with the dial peers. The POTS dial peer is the same as the one defined in the VoFR 
lab. However, you can see that the session target defined on the VoIP dial peer now points to 
an IP address rather than an interface and DLCI number. The IP address of the session target 
can be any interface on the router that you are directing your call to. Best practice would 
dictate that this address should be the IP address of a loopback interface because it is the 
most stable. That is, it should always be logically up as long as the router is powered up. In 
the example, we pointed the session target at the far end IP address of the Serial 
subinterface. 


IP RTP header compression reduces the 40- byte |P+UDP+RTP header to 2 to 4 bytes, 
thereby reducing the bandwidth required per voice call on point-to-point links. The header is 
compressed at one end of the link and decompressed at the other end. Another standard 
name for this technique is CRTP, which stands for compressed RTP. To configure IP RTP 
header compression, you need to configure the ip rtp header-compression command 
under the serial interface, or the frame-relay ip rtp header-compression command under 
the Frame Relay subinterface. 


Frame Relay IP RTP priority is used to reserve a strict priority queue on a Frame Relay PVC 
for a set of RTP packet flows belonging to a range of User Datagram Protocol (UDP) 
destination ports. The theory behind IP RTP priority is that VoIP traffic is identified by the fact 
that it uses a well-known UDP port range (16384-32767). Although the actual ports used are 
dynamically negotiated between end devices or gateways, all Cisco VoIP products utilize the 
same port range. When the router recognizes the VoIP traffic, it places this traffic into a strict 
priority queue. The amount of traffic that is placed into the priority queue is controlled ata 
user-configurable rate by the system. This priority queue always is serviced before any other 
traffic, which means that jitter and delay of VoIP traffic is minimized. 


IP precedence gives voice packets a higher priority than other IP data traffic. The ip 

precedence command is used by the Cisco 3600 router to differentiate voice traffic from 

data traffic. So, you need to ensure that the data IP packets do not have the same IP 

precedence as that of the voice packets. In IP precedence, the numbers 1 through 5 identify 

classes for IP flows; the numbers 6 through 7 are used for network and backbone routing and 
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updates. It is recommended that IP precedence 5 be used for voice packets. 


Example 6-5 shows the configuration for the voip2 router. 


Example 6-5 Configuring Voice over IP on voip2 


Current configuration: 

! 

version 12.1 

service timestamps debug uptime 
service timestamps log uptime 


no service password-encryption 
! 
! 


enable password cisco 


ces 1/0 

! 

ip subnet-zero 

no ip domain-lookup 
! 


lane client flush 
! 


i} 

! 
controller T1 1/0 

i} 

i} 

! 

interface FastEthernet0/0 
no ip address 

shutdown 

duplex auto 

speed auto 

1 

interface FastEthernet0/1 
no ip address 

shutdown 

duplex auto 

speed auto 

1 

interface ATM1/0 

no ip address 

shutdown 

no atm scrambling cell-payload 


no atm ilmi-keepalive 
! 


457 


interface Serial2/1 
no ip address 
shutdown 


interface Serial2/2 
no ip address 
shutdown 


interface Serial2/3 
no ip address 
shutdown 


router rip 
network 150.150.0.0 


ip classless 
no ip http server 


voice-port 3/0/0 


voice-port 3/0/1 


voice-port 3/1/0 


voice-port 3/1/1 
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1 
line con 0 
password cisco 
transport input none 
line aux 0 
password cisco 
line vty 0 4 
password cisco 
login 
1 


end 


Now that both router configurations are complete, pick up the phone set on voip1 and dial 
the digits 2222. If your configurations are correct and your routers are physically connected 
as described earlier, you should be able to complete a successful call. Hang up the phone set 


on voipl1 and try placing a call from voip2 by dialing 1111. 
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Lab 15c: Configuring Voice over ATM—Part | 
Equipment Needed 


For the Voice over ATM lab, you need the following equipment: 


e Two Cisco voice-capable routers, each with an FXS interface where you will connect 


your analog phone sets. Each should have at least one ATM interface for our point-to- 
point connection. 


e Two analog phone sets. 
Physical Layout and Prestaging 


e Connect the two Cisco voice-capable routers in a point-to-point configuration through 
the ATM interfaces. Remember to cross over the fiber (refer to Figure 6-28). 


e Connect an analog phone set to each of the FXS interfaces on the Cisco voice- capable 
routers, as shown in Figure 6-28. 
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Lab 15c: Configuring Voice over ATM—Part II 
Lab Walkthrough 


Now, take a look at the configurations that you will use on each of these routers to 
accomplish your Voice over ATM lab. The configuration of the voice ports, dial peers, and 
QOS mechanisms is discussed. For the purpose of this lab, the Cisco voice-capable routers 
have host names of voatm1 and voatm2. Example 6-6 shows the configuration for voatm1. 


Example 6-6 Configuring Voice over ATM on voatm1 


Current configuration: 

| 

version 12.1 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
! 

hostname voatml 

! 


enable password cisco 


! 
! 
! 
! 
! 
! 


ces 1/0 
i} 


ip subnet-zero 
! 


lane client flush 
! 


! 
! 
! 
! 


controller T1 1/0 

i} 

i} 

! 

interface FastEthernet0/0 
no ip address 

shutdown 

duplex auto 

speed auto 

1 
interface FastEthernet0/1 
no ip address 

shutdown 

duplex auto 


speed auto 
i} 
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interface Serial2/0 
no ip address 
shutdown 


interface Serial2/1 
no ip address 
shutdown 


interface Serial2/2 
no ip address 
shutdown 


interface Serial2/3 
no ip address 
shutdown 


ip classless 
no ip http server 


voice-port 3/0/0 


voice-port 3/0/1 


voice-port 3/1/0 


voice-port 3/1/1 


line con 0 

transport input none 
line aux 0 

line vty 0 4 


0) 
2) 
Q. 


The following is a description of the configuration parameters on the ATM interface. 


The no atm scrambling cell-payload randomizes the ATM cell payload frames to avoid 
continuous nonvariable bit patterns and improve the efficiency of ATM's cell delineation 
algorithms. Normally, the default setting for this command is sufficient, with no specific 
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command required. By default, scrambling is off for Tl or E1 links. 


To enable or disable ILMI connectivity procedures and to change the ILMI keepalive poll 
interval, use the atm ilmi-keepalive interface configuration command. To disable I LMI 
connectivity procedures, use the no form of this command. This is disabled by default. 


To configure the real-time variable bit rate (VBR) for Voice over ATM connections, use the 
vbr-rt ATM virtual circuit configuration command. vbr-rt peak-rate average-rate burst. The 
parameters for the vbr-rt command are described as follows: 


e peak-rate— The peak information rate (PIR) of the voice connection in kbps. The 
range is 56 to 10000. Peak value: (2 x the maximum number of calls) x 16 kb. 


e average-rate— The average information rate (AIR) of the voice connection in kbps. 
The range is 1 to 56. Average value: (1 x the maximum number of calls) x 16 kb. 


e burst— Burst size in number of cells. The range is 0 to 65536. Burst value: x 4 the 
maximum number of calls. 


encapsulation aal5mux voice sets the encapsulation of the PVC to support voice traffic. 


pvc 1/ 150 (pvc vpi/vci) creates an ATM PVC for voice traffic and enters virtual circuit 
configuration mode. 


The POTS dial peer is configured the same way as in the VoFR and VoIP labs and is 
associated with voice port 3/0/0. 


The VoATM dial peer is not pointing at an IP address, as it was in the VoIP lab, but now 
points to an ATM interface and a voice PVC. 


Example 6-7 shows the configuration for the second router in your VoOATM lab. The 


configurations are nearly identical with the exception of the atm clock internal configuration 
parameter on the ATM interface. This means that the transmit clock is generated internally. 


Example 6-7 Configuring Voice over ATM on voatm2 


Current configuration: 

| 

version 12.1 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
! 

hostname voatm2 

! 


enable password cisco 
1 


! 
! 
! 
! 
! 
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ces 1/0 

! 

ip subnet-zero 

! 

lane client flush 
! 

! 

! 


1 
controller T1 1/0 

i} 

i} 

! 

interface FastEthernet0/0 
no ip address 

shutdown 

duplex auto 

speed auto 

i} 

interface FastEthernet0/1 
no ip address 

shutdown 

duplex auto 

speed auto 


interface Serial2/0 

no ip address 
encapsulation frame-relay 
shutdown 


frame-relay lmi-type cisco 
i} 


interface Serial2/1 
no ip address 
shutdown 

! 

interface Serial2/2 
no ip address 
shutdown 

! 

interface Serial2/3 
no ip address 
shutdown 

! 

ip classless 

no ip http server 

! 

! 
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voice-port 3/0/0 
i} 


voice-port 3/0/1 
1 


voice-port 3/1/0 
1 


voice-port 3/1/1 


! 

line con 0 

transport input none 
line aux 0 


line vty 0 4 
! 


end 


Now that both router configurations are complete, pick up the phone set on voatm1 and dial 
the digits 1000. If your configurations are correct and your routers are physically connected 

as described earlier, you should be able to complete a successful call. Hang up the phone set 
on voatm1 and try placing a call from voatm2 by dialing 1000. 
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Lab 15d: Optional Private Line Automatic Ring Down (PLAR) 
Connection 


As on optional lab, we have set up a private line automatic ring down (PLAR) lab. This is 
sometimes referred to as the Bat Phone. You can complete this lab by referring back to the 
VoFR lab that you did previously. All you need to do to create the PLAR connection is add one 
configuration statement under your voice port. Example 6-8 shows the configuration for 


router vofr2 to accomplish this. 


Example 6-8 Configuring a PLAR Connection 


hostname vofr2 

! 

enable password cisco 
! 

ip subnet-—zero 


no ip domain-—lookup 
! 


voice-port 3/0/0 

timeouts call-disconnect 0 
connection plar 1111 

! 
voice-port 3/0/1 

timeouts call-disconnect 0 
! 
voice-port 3/1/0 

timeouts call-disconnect 0 
! 
voice-port 3/1/1 

timeouts call-disconnect 0 
! 

dial-peer voice 22 pots 
destination-pattern 2222 
port 3/0/0 

! 
dial-peer voice 1111 vofr 
destination-pattern 1111 
session target Serial1/0 200 
! 

! 

interface Ethernet0/0 

no ip address 

no ip directed-broadcast 
shutdown 

! 

interface TokenRing0/0 

no ip address 

no ip directed-broadcast 
shutdown 

ring-speed 16 

! 
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interface Seriali/0 

no ip address 

no ip directed-broadcast 
encapsulation frame-relay 
frame-relay traffic—shaping 

! 

interface Serial1/0.1 point-to-point 
ip address 150.150.10.2 255.255.255.0 
no ip directed-broadcast 
frame-relay interface-dlci 200 
class voice 
vofr cisco 

! 

interface Seriali/1 

no ip address 

no ip directed-broadcast 
shutdown 

! 

interface Seriali/2 

no ip address 

no ip directed-broadcast 
shutdown 

! 

interface Seriali1/3 

no ip address 

no ip directed-broadcast 
shutdown 

! 

interface FastEthernet2/0 

no ip address 

no ip directed-broadcast 
shutdown 

! 

router igrp 1 

network 150.150.0.0 

! 

ip classless 

no ip http server 

! 

! 

map-class frame-relay voice 
frame-relay cir 768000 
frame-relay bc 1000 
frame-relay mincir 120000 
no frame-relay adaptive-shaping 
frame-relay fair-—queue 
frame-relay voice bandwidth 78000 
frame-relay fragment 1500 

! 

! 

line con 0 

password cisco 

transport input none 

line aux 0 

password cisco 

line vty 0 4 

password cisco 
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With this configuration in place, all you have to do is pick up the telephone set on router 
vofr2 and it will automatically dial 1111 and connect you to the telephone set connected to 


router vofrl. 
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Chapter 7. WAN Protocols and Technologies: 
Integrated Services Digital Network (ISDN) 


Authoring contribution by Daniel Keller 


Integrated Services Digital Network (ISDN) is basically the digital version of the Public 
Switched Telephone Network (PSTN). It offers a common platform for integrating voice, 
video, and data services globally. When discussing ISDN, we actually are talking about 
Narrowband ISDN (N-ISDN). The other type of ISDN is referred to as Broadband ISDN (B- 
ISSDN), which provides high-speed transmissions and is the foundation behind ATM, which is 
addressed in more depth in Chapter 8, "WAN Protocols and Technologies: Asynchronous 
Transfer Mode (ATM)." 
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ISDN Development, Components, and Mechanics 


Once upon a time, in the early days of the public telephone network, telephone users were 
began replacing the analog circuits in the core of their networks with packet-based digital 
signals. Analog circuits still were delivered to the telephone users at the local loop level. ISDN 
delivers the digital circuits directly to the customers, enabling them to carry a wide variety of 
traffic over the network. Therefore, ISDN enables users to carry voice, video, data, and other 
traffic over the existing telephone wiring. When ISDN became an emerging technology, it was 
envisioned to become the leading worldwide digital network technology, providing access to 
everyone. Now, with the emergence of xDSL and cable modems, ISDN is losing favor with 
the home access market. However, ISDN is still a major player in the business market, where 
it is used to back up primary links and where PRI/E1s are used to carry data and V.90 remote 
dial-in access. It is also more readily available than DSL and cable, allowing the majority of 
home users who fail to qualify for cable or DSL to purchase ISDN service. 


A standards committee was developed in 1984 to coordinate the ISDN movement, called the 
International Telephone and Telegraph Consultative Committee (CCITT), now known as the 
International Telecommunications Union (ITU). The ITU organizes the ISDN protocols 
according to three general topic areas: 


e Protocols that begin with the letter E deal with telephone network standards for ISDN. 
For example, the E.164 protocol describes international addressing. 

e Protocols that begin with the letter | deal with concepts, terminology, and general 
methods. The |.100 series of protocols deal with general ISDN concepts and the 
structure of other |-series recommendations. |.200 deals with the service aspects of 
ISDN, whereas |.300 describes network aspects, and 1.400 describes how the User 
Network Interface (UNI) is provided. 

e Protocols beginning with the letter Q cover how switching and signaling should 
operate. Q.921 describes the ISDN data-link processes of Link Access Protocol 
(LAPD), which functions like Layer 2 processes in the OSI model and is an 
encapsulation option on the ISDN D channel. Q.931 specifies Layer 3 functions. 


Debugging Q.921 and Q.931 sometimes can be useful for troubleshooting ISDN connectivity 
problems, and this is discussed in more detail later in the chapter. 


The major advantage of ISDN is that it allows multiple digital channels to operate 
simultaneously over one circuit. Currently, there are three types of ISDN channels: 


e B (Bearer) channel— 64 kbps used for user traffic. Some ISDN switches limit B 
channels to a capacity of 56 kbps. 


e D (Data) channel— 16 kbps or 64 kbps, depending on the type of ISDN circuit. This 
channel is used for ISDN signaling, as well as call setup and teardown. 


e H channel— Provides a way to bond multiple B channels. They typically are not used 
in North America. H channels are implemented as follows: 


- HO— 384 kbps (six B channels) used for high-quality audio/high speed digital 
information 


- H1LO— 1.472 Mbps (23 B channels) used for teleconferencing/ digital 
information 
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- H1L1— 1.536 Mbps (24 B channels) used for teleconferencing/ digital 
information 


- H1L2— 1.92 Mbps (30 B channels) used for teleconferencing/ digital 
information 


- H4— 150 Mbps (approximate) used for high-definition TV 


Cisco supports the following two ISDN interface types, which combine the channel types in 
the preceding list: 


e Basic Rate Interface (BRI )— One 16-kbps D channel + two B channels 


e Primary Rate Interface (PRI)— 1 64-kbps D channel + 23 B channels in North 
America and Japan, for a total capacity of 1536 kbps. 1 64-kbps D channel + 30 B 
channels in Europe and other parts of the world, for a total capacity of 1984 kbps. 


ISDN Components and Reference Points 


To access the ISDN network, customer premises equipment (CPE), which is the local 
terminating equipment, is used. This equipment performs the functions needed for properly 
connecting to the ISDN network. The following describes the types of ISDN CPE options: 


e TE1 (Terminal Equipment Type 1)— Designates a device with a native ISDN 
interface. 


e TE2 (Terminal Equipment Type 2)— Designates a device that does not include a 
native ISDN interface and requires a terminal adapter (TA) for its ISDN signals. 


e NT1 (Network Termination 1)— Designates a device that converts the BRI signals 
into a form used by the ISDN digital line, and is the boundary between the carrier's 
ISDN network and the CPE. 


e NT2 (Network Termination 2)— Designates a device that aggregates and switches 
all ISDN lines at a customer location. This typically is incorporated into a corporate 
private branch exchange (PBX). 


e TA (Terminal Adapter)— Used by a TE2 device to convert EIA/TIA-232, V.35, and 
other signals into BRI signals. 


Because CPE can include one or more of these functions, the way in which they connect to 
the other ISDN devices can vary. Because of this, the ISDN standards refer to these various 
interfaces as reference points. The reference points simply define the logical points between 
the previous CPE groups. Figure 7-1 shows the reference points, which are described as 


follows: 


Figure 7-1. ISDN Reference Points 
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e R— The connection between a non-|SDN-compatible device (TE2) anda TA 


e S— The connection between the end-user CPE and the NT2 
e T— The connection between the NT2 and the NT1 
e U— The connection between the NT1 and the carrier's ISDN network 


In most implementations for BRI users, an NT2 is not used and usually is found only in PBXs. 
In this case, the CPE-to-carrier interface is referred to as the S/T interface. 


Generally, routers come with an integrated S/T ISDN interface, so the reference points would 
look like they do in Figure 7-2. 


Figure 7-2. 1SDN Reference Points for a Router with an Integrated S/ 
T ISDN Interface 
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ISDN network 


Cisco ISDN router 


Additionally, Cisco routers can be purchased with an S/T interface and integrated NT1, so 
reference points S, T, and U would all be incorporated into the BRI/PRI interface of the Cisco 
router. 


In North America, all ISDN lines are connected to the ISDN switch at the local central office 
(CO) through a U interface. This U interface requires network termination to convert it into an 


S/T interface that actually connects to your end equipment. An NT-1 is a separate unit that 
serves this function and also provides power to your ISDN line. In Europe, the NT-1 is 
included in telco- provisioned ISDN lines, so all you need is the S/T interface. 


When working with Cisco routers, it is important to determine whether the unit has an S/T 
interface, which will require an external NT-1, or a U interface with a built-in NT-1. Check 
your hardware manual to determine whether you have the proper equipment. 


ISDN Layers 


ISDN deals with Layers 1, 2, and 3 of the OSI reference model. ISDN connectivity works only 
if all three of these layers are operational. Layer 1 is the physical layer, dealing with the 
physical connections between the router and the ISDN circuit. Layer 2, the data link layer, 
deals with the Q.921 protocol on the D channel and the encapsulation options for each B 
channel (HDLC and PPP). Q.921 handles the signaling between the router ISDN interface and 
the ISDN switch. Layer 3, the network layer, includes the Q.931 protocol over the D channel 
and network layer protocols (IP, IPX, AppleTalk, and so on) over the B channels. Q.931 
handles call setup messages between the calling and called parties. It is important to fully 
understand the various protocols that operate over the D and B channels when configuring 
and troubleshooting ISDN. 


ISDN Encapsulation Options 


ISDN routers can support both PPP and HDLC encapsulations. HDLC is the default 
encapsulation, but the vast majority of ISDN routers use PPP. The main reason that PPP is 
chosen over HDLC is because HDLC cannot use both B channels simultaneously. With HDLC, 
both B channels can be up, but one channel is used to send and the other is used to receive 
traffic. Each B channel has the capability to provide full duplex (send and receive at the same 
time), so by using HDLC, you are essentially cutting the possible data rate over the link in 
half. 


PPP was covered in Chapter 4. 
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ISDN Configuration Basics 


Now that the boring specifics of ISDN are behind us, it is time to dive into the more 
interesting topic of how to actually configure Cisco routers to use ISDN. 


Unfortunately, there is currently no method of configuring ISDN in a lab environment without 
the use of actual ISDN circuits or a costly ISDN simulator. Nonetheless, ISDN is a core topic 
in the CCIE routing and switching lab exam, and the only way to learn the topic is through a 
great deal of hands-on practice. 


To configure basic ISDN, only two things must be configured: 


e ISDN switch type settings 
e Service profile identifiers (SPIDs) 


The SPID is a number assigned to a fully initializing ISDN terminal that enables the Stored 
Program Control Switching System (SPCS) to uniquely identify the ISDN terminal at Layer 3 
of the D-channel signaling protocol. 


A SPID is assigned to each B channel and usually resembles a phone number followed by 
some extra digits. For example, if your router is connecting to a Siemens ISDN switch, the 
SPIDs would typically be of the type aaabbbbbbbccdd, where 


aaa is the three-digit area code 
bbbbbbb is the seven- digit phone number 


For national ISDN switches, the most frequently used SPID value is NPANXXXXXX0101, based 
on the configurations being installed today. The NPA/NXX is simply the carrier's term for the 
local area code/access number. 


Not all ISDN switches actually require that the SPIDS be configured, but the majority of them 
do. The ISDN provider can provide you with the information that you need. Currently, Cisco 
routers support a number of different switch type options, as documented in Table 7-1. 


Table 7-1. Supported ISDN Switch Types 


Identifier Description 


basic-1tr6 [German 1TR6 ISDN switches 
pasic-5ess [AT&T basic rate switches 
Ib asic-dms100 INT DMS-100 basic rate switches 


basic-net3 NET3 ISDN and Euro-ISDN switches (UK and others), also 
called E-DSS1 or DSS1 


Ib asic-nil National ISDN-1 switches 
basic-nwnet3 [Norway Net3 switches 
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basic-nznet3 New Zealand Net3 switches 
basic-ts0O13 Australian TSO13 switches 


None INo switch defined 
IN |) apanese NTT ISDN switches (ISDN BRI only) 


tt 
AT&T 4ESS switch type for the United States (ISDN PRI 
primary-4ess only) 


AT&T 5ESS switch type for the United States (ISDN PRI 
primary-5ess 


only) 
primary- NT DMS-100 switch type for the United States (ISDN PRI 
dms100 only) 
primary-net5 NET5 ISDN PRI switches (Europe) 
primary-ntt INS-Net 1500 for Japan (ISDN PRI only) 
jprimary-ts014 Australian TS014 switches (ISDN PRI only) 
vn2 French VN2 ISDN switches (ISDN BRI only) 
vn3 French VN3 ISDN switches (ISDN BRI only) 
vn4 French VN4 ISDN switches (ISDN BRI only) 


You need to contact your ISDN service provider to determine which switch type is being 

used. The switch type can be configured in both global and interface configuration modes. If 
it is specified in global mode, the switch type applies to all ISDN interfaces in the router. If it 
is placed in interface mode, it is applied to the interface only. If both are specified, the switch 
type that is configured in interface mode overrides the switch type set globally for that 
interface. For example, if you have a router with six ISDN interfaces and five of them connect 
to a DMS-100 switch, with the other connecting to an NI switch, you can use the isdn 
switch-type basic-dms100 command globally and then use the command isdn switch- 
type basic-ni in interface mode for the specific NI connected BRI interface. 
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Configuring Dial-on-Demand Routing (DDR) 


For ISDN to work properly, dial-on-demand routing (DDR) options must be created on the interface. 
Often, ISDN links are used to back up point-to-point or Frame Relay circuits. If not configured 
correctly, the ISDN link can stay up constantly or can continuously connect, hang up, and then 
connect again. Because ISDN carrier's normally charge usage by the minute, a small configuration 
error can result in a customer getting ISDN bills of more than $1000 per month. Unless you enjoy 
long "discussions" with your manager, you probably want to avoid this. DDR works using the concept 
of user-defined "interesting" traffic. The ISDN link will come up only under the circumstances 
permitted, or when certain interesting traffic is passed to the ISDN interface. The ISDN call will stay 
up until no interesting traffic has passed through the ISDN interface for a user-specified period of 
time, using the dialer idle-timeout command in interface configuration mode. The default idle 
timeout length is 120 seconds. The length of time that can be configured is as follows: 


ISDN_Router (config-if) #dialer idle-timeout ? 
<1-2147483> Idle timeout before disconnecting a call 


This time is specified in seconds. An important thing to note here is that all types of traffic will pass 
over the ISDN link as long as the connection is active, not just the traffic specified as "interesting." 


However, only traffic specified as interesting will keep the call up. Think of the dialer idle timeout 
value as a countdown timer. When traffic specified as interesting initiates an ISDN connection, the 
timer starts, counting down to 0. When the timer reaches 0, the connection is dropped. This timer is 
reset only when the traffic specified as interesting (which was defined in the dialer lists) passes 
through the ISDN link. As you will see, there are a number of ways to accomplish DDR; the trick is to 
configure the routers so that an ISDN connection is established when needed, while suppressing the 
connection when it is not needed. 


The two options that are discussed with DDR in this chapter are legacy DDR and dialer profiles. 
Legacy DDR deals with the capability to enable a connection only when there is traffic to send. Here, 
the dialer parameters are specified on the physical ISDN interface. Dialer profiles include the use of 
logical dialer interfaces, which are separate from the physical ISDN interface, to issue a DDR call. In 
this setup, the bulk of the configuration commands are placed on the logical dialer interfaces, and 
only a few necessary commands actually are placed on the physical ISDN interface. Examples of both 
legacy and dialer profile configurations are covered in this chapter. 


To configure DDR, you must keep in mind that there are two ends to an ISDN call: the calling router 
and the called router. The calling router is the router that will initiate the ISDN call, and the called 
router is the destination router where the ISDN link terminates. Note that each router can serve as 
both a calling and a called router; however, when setting up DDR, you work from one side at a time. 
One router might have different requirements for placing a call than the other router. Figure 7-3 


shows a typical simple ISDN setup. 


Figure 7-3. 1SDN Backing up a Primary Link 
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Normally, the remote office will initiate the ISDN connection, therefore becoming the calling router. 
The headquarters router becomes the called router. Larger networks might have numerous remote 
offices that use routers with BRI interfaces, with the headquarters router having a PRI interface to 
handle multiple ISDN calls at once. 


In this setup, the Frame Relay link is used as the primary, with the ISDN link backing up the Frame 
Relay, and is used only when there is a Frame Relay outage. Typically, the remote office is the calling 
router, and the headquarters location is the called router. As you will see, there are numerous ways in 
which to accomplish this. 


To configure DDR, perform the following steps: 


Step 1. Configure the ISDN switch type and SPID information, if necessary. 
Step 2. Specify the interesting traffic that will bring up the ISDN call. 


Step 3. Configure the dialer information. This includes the number to call to reach the called 
router, as well as any other parameters associated with the call. 


Step 4. Configure any other optional parameters associated with the ISDN interface. These 
advanced topics include interface encapsulation, dialer idle-timeout, authentication options, 
callback for billing purposes, and so on. Most of these options are covered later in the chapter. 


Step 5. Route traffic over the ISDN line. You can use a number of options here, such as 
specifying floating static routes, using the backup interface command, or using dynamic 
routing protocols together with their respective options. These options include the following: 


For OSPF: OSPF demand circuit 
For EIGRP, |GRP, OSPF: Dialer watch 
IGRP, RIP: Snapshot routing 


All: Backup interface 


These routing topics are covered later in the chapter, and these options are demonstrated through 
different labs. You will find many parallels in these examples to those found in Chapter 4 for the sake 


of completeness. 


Within the scope of the CCIE lab, you will be provided the switch type and the SPID numbers, so there 
won't be a lot of guessing. In the real world, ISDN is a huge pain because of service provider issues; 
however, most typical noncarrier problems are the result of incorrectly entering information (that is, 
SPIDS or switch type). The other setup for bringing up an ISDN line is to save the router configuration 
and power-reset the router. Within the scope of the lab exam, if you are highly confident that you 
have your router configured correctly and that you have the correct working cable plugged ingethe 


correct jack, don't hesitate too long to notify the instructor that you are having problems with the line 
and you are wondering whether there have been problems with the line in the past. As with all other 
questions to the instructor, ask questions as if the instructor is a customer! 


Step 1: Configure the ISDN Switch Type and SPID Information 


Referring back to Figure 7-1, you can specify the ISDN switch type in either global or interface 
configuration mode. Because the routers in this diagram have only one BRI interface, it does not 
matter where it is applied. For purposes here, specify it in interface mode along with the SPID 
information, as demonstrated in Example 7-1. 


Example 7-1 Setting the SPID Information on a BRI Interface 


ISDN_Router#config terminal 

Enter configuration commands, one per line. End with CNTL/Z. 
ISDN_Router (config) #interface BRIO 

ISDN_Router (config-if) #isdn switch-type basic—dms100 
ISDN_Router(config-if) #isdn spidl 61293198331111 ldn 
ISDN_Router(config-if) #isdn spid2 61293198461111 ldn 


The LDN is the local directory number, which is the seven-digit number assigned by the service 
provider and used for call routing. The LDN is not necessary for establishing |SDN-based connections, 
but it must be specified if you want to receive incoming calls on the second B channel. The LDN is 
required only when two SPIDs are configured (for example, when connecting to a DMS or NI1 switch). 
Each SPID is associated with an LDN, and configuring the LDN causes incoming calls to B channel 2 to 
be answered properly. If the LDN is not configured, incoming calls to B channel 2 might fail. 


CAUTION 


Take caution when entering the SPID information because it can be easy to "fat finger" 
the numbers. We have done this often and then have wasted time trying to troubleshoot 
what | thought was an ISDN circuit problem, only to realize that we typed in the wrong 
SPID. 


Step 2: Specify Interesting Traffic 


Interesting traffic is defined as the kind of traffic that is allowed to initiate an ISDN connection. When 
this connection has been established, the link will stay up as long as the type of traffic that is defined 
as interesting traverses the ISDN link. 


This step is performed using the dialer-group interface command, along with a special access list 
that defines the interesting traffic, called a dialer list, in global configuration mode. The syntax for the 
dialer-list is as follows: 


dialer-list dialer-group protocol protocol-name [permit | deny | list] access-list 


number. 


Here, the dialer-group argument is used to define the interesting traffic for the interface. This is the 
Same number that was entered into the dialer-group command. Be sure that the number specified in 
the dialer-group number matches the dialer-list number. For example, if you want to specify all IP 
traffic as interesting, use the command dialer list 1 protocol ip permit. 


You also can use extended dialer lists to define a more granular set of conditions that will define the 
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interesting traffic, by combining a dialer list with an extended access list. For example, if you want to 
specify that only traffic originating from 10.1.1.0/24 destined for 10.1.2.0/24 can initiate an ISDN 
call, you would accomplish this through the following commands: 


ISDN_Router (config) #dialer-list 1 protocol ip list 101 
ISDN_Router (config) #access-list 101 permit ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255 


The first command ties the dialer list to an extended access list; this example uses access list 101. By 
using extended access lists, you can be more specific in what types of traffic you define as interesting. 


Step 3: Configure Dialer Information 


A few options should be considered when configuring the dialer information. The most basic way to do 
this is through the dialer-string interface command. Configuring the dialer information in this 
manner has some limitations—namely, the dialer string will be used for all outgoing calls, regardless 
of the actual destination. This works well if the calling router has only one other router to connect to, 
but not if the ISDN router has the capability to dial into more than one other ISDN router. A more 
feature-rich way of accomplishing this step is using the dialer-map command. Here, a router can 
more accurately determine which ISDN router to dial into based on the Layer 3 address. These two 
options commonly are referred to as legacy DDR. Finally, the last option is to use a set of logical 
dialer interfaces. A major advantage to using logical dialer interfaces is that an ISDN router has the 
capability to dial into multiple other ISDN routers simultaneously. We will now demonstrate these 
three options using the simplified network in Figure 7-4 as a reference. 


Figure 7-4. Simplified |SDN Network 
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Configuring Dialer Information, Method 1: Using Dialer Strings 


This is the simplest (and least robust) way to configure ISDN. In Example 7-2, all traffic specified as 
interesting initiates the call, which will be placed to the number specified in the dialer string. This 
works well for situations in which there is only one possible destination, but not in networks where 
there are multiple ISDN sites that need access to each other directly. Note that the BRI interface 
encapsulation in this example has been set to PPP. In this situation, it is not necessary and could have 
just as easily been left with the default encapsulation, HDLC. 


Example 7-2 Cheech and Chong Router Configurations Using Dialer Strings 


Cheech#show running-config 


version 11.2 

no service password-encryption 
no service udp-small-servers 
no service tcp-small-servers 

! 

hostname Cheech 

! 


enable password cisco 
! 
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isdn switch-type basic-—dms100 
! 


interface Ethernet0 

no ip address 

shutdown 

! 

interface Serial0O 
no ip address 

shutdown 

! 

interface Seriall 

no ip address 

shutdown 

! 

interface BRIO 

ip address 175.10.23%.1 255.255.255.292 

encapsulation ppp 

isdn spidl 61293199371111 <SPID associated with the first B channel 
isdn spid2 61293199381111 <SPID associated with the second B channel 
dialer string 6129319833 <number to dial for all outgoing connections 
dialer-group 1 

! 


ip classless 
! 


dialer-list 1 protocol ip permit <all ip traffic is interesting 
! 

line con 0 
exec-timeout 0 0 
privilege level 15 
logging synchronous 
line aux 0 

line vty 0 4 
password cisco 
login 

! 


end 


Chong#show running-config 

! 

version 11.2 

no service password-encryption 
no service udp-small-servers 
no service tcp-small-servers 
! 

hostname Chong 

! 

enable password cisco 

! 

isdn switch-type basic-—dms100 
! 

interface Ethernet0O 

no ip address 

shutdown 

! 

interface Serial0O 

no ip address 

shutdown 


! 
interface Seriall 
no ip address 


shutdown 
! 
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interface BRIO 
ip address 175:10.23.2 255525525 52252 
encapsulation ppp 
Lsdn. spidl. 61293198331111 <SPID for the first B channel 
isdn spid2 61293198461111 <SPID for the second B channel 
dialer string 6129319937 <number to call for all connections 
dialer-group 1 
! 


no ip classless 
! 


dialer-list 1 protocol ip permit <all ip traffic is interesting 
! 

line con 0 
exec-timeout 0 0 
privilege level 15 
logging synchronous 
line aux 0 

line vty 0 4 

no login 

privilege level 15 

! 


end 


In this example, both routers can initiate ISDN calls. If you want only Cheech to be capable of calling 
into Chong, and not vice versa, you could omit the dialer string command in Chong's configuration. 


NOTE 


Although the configurations in Example 7-2 are fairly straightforward, you might not be 
familiar with some commands. Both routers have some serious security holes that 
purposely were done. Under the line con O, we added the privilege level 15 command. 
This enables anyone connected to the router to go straight to enable mode without 
typing in the enable password. We also added the exec-timeout 0 0 command, which 
means that all console connections will never time out. This was done only to save the 
time and effort that it takes to go into enable mode and type in a password to get into 
enable mode. We did something similar under the vty so that when you Telnet to a 
router, you go automatically into enable mode without a password prompt. Although this 
is useful in a lab environment, these commands never should be implemented in a live 
production router. One final command to point out is the logging synchronous 
parameter under the console heading. This prevents the router from interrupting you 
while you are in the middle of typing a command. By default, the router logs all events to 
the console, which can make it easy to lose your place while typing in commands. An 
alternative to this is the no logging console command, but we prefer the logging 
synchronous command because it allows you to see the console log entries, which is 
usually useful, without the bothersome interruptions that occur by default. 


Configuring Dialer Information, Method 2: Using Dialer Maps 


The problem with using dialer strings occurs when multiple ISDN connections are involved. In the 
network illustrated in Figure 7-5, the Headquarters router would require two sets of dialer strings to 
connect to the remote offices, Cheech and Chong. However, because the Headquarters router has no 
way of associating IP addresses with dialer strings, it might dial the Cheech router when it needs to 
connect to the Chong router. 


Figure 7-5. Dialer Map Configuration 
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A way to map IP addresses to dialed numbers is to use dialer maps. Using dialer maps tells the router 
which dial string to call when it wants to connect to a specific |P address. Example 7-3 demonstrates 
the router configuration using dialer maps. 


Example 7-3 Example Dial String Configuration for the Headquarters Router 


interface BRIO 

ip address 175.10.23.3 255.255.255.248 
encapsulation ppp 

isdn spidl 61293193601111 

isdn spid2 61293197761111 

dialer map ip 175.10.23.1 name Cheech 6129319937 
dialer map ip 175.10.23.2 name Chong 6129319833 
dialer-group 1 


The IP address space is set up so that when the Headquarters router calls either Cheech or Chong, 
they are in the same subnet. 


You should be aware of a couple of other options when using dialer maps. One is that the connection 
speed for each B channel can be manually set to either 56 kbps or 64 kbps, using the speed 
keyword. Another useful command is the name keyword, which can be placed at the end of the dialer 
map statement. With CHAP and the name keyword included in the dialer map command, both the 
telephone number and the name for a given next-hop address are compared to the names of the 
routers already connected. In this way, calls to destinations to which connections already are 
established can be avoided. 


More important is the broadcast keyword option. If you want to pass routing updates across the 
ISDN connection, (routing protocols use broadcast packets to advertise their routes), you must use 
the broadcast keyword in the dialer map statement, as demonstrated in Example 7-4. This is much 


like Frame Relay, in that the broadcast statement must be configured in all frame-relay map 
statements if you want to pass routing updates. 


Example 7-4 Using the broadcast Statement: Headquarters Router 
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Configuration 


interface BRIO 

ip address 175.10.23.3 255.255.255.248 

encapsulation ppp 

isdn spidl 61293193601111 

isdn spid2 61293197761111 

hae aR ee Or aaa ae Cree ere ed ease ee eet 
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dialer-group 1 


The configuration in Example 7-4 enables the passing of routing updates and other broadcast traffic. 


However, if you don't want this traffic to actually trigger calls, you need to specify restrictive dialer 
lists or make the ISDN interface passive under the routing process. 


Configuring Dialer Information, Method 3: Using Logical Dialer Interfaces 


Dialer profiles were introduced in Cisco 1|OS Software Release 11.2, and they offer the capability to 
separate the configuration parameters used in legacy DDR from the physical interfaces. It is perhaps 
the most complex method of configuring DDR, but it offers the greatest amount of flexibility and 
design options. It works through the creation of logical dialer interfaces, where the configuration 
options are placed. These dialer interfaces are bound to a physical interface only when a connection is 
made, through the use of dialer pools. 


To configure dialer profiles, first you must remove all legacy DDR commands under the BRI 0 
interface. Then you create a logical interface, dialer 1, and place all configuration options and Layer 3 
information on that interface. The steps for configuring dialer profiles are as follows: 


Step 1. Remove all legacy DDR commands from the BRI 0 interface. 1OS will not allow you to 
map a dialer interface to a physical interface until this is done. 


Step 2. Configure a logical interface using the interface dialer X command, where X can be 
any value between 0 and 255. 


Step 3. Configure a dialer remote-name on the dialer interface. Only one remote name can 
be specified, and this should be the name of the router with which you want to make an ISDN 
connection. 


Step 4. Map the logical interface to the physical interface. This is done by associating a dialer 
pool on the logical interface to the dialer pool-member on the physical interface. This is 
done with the dialer pool-member x command on the physical interface and the dialer pool 
x command on the logical dialer interface, where x can be any integer from 1 to 255. The 
number specified must be the same for both interfaces, and there can be only one dialer pool 
per dialer interface. 


Step 5. Define the interesting traffic. This is needed only for routers that initiate calls (calling 
routers), and it is done the same way as legacy DDR, except that the commands are now 
placed on the logical interface. 


Step 6. Provide a dialer string to call on the logical interface. This is the number to call to 
connect to another ISDN router. Note here that dialer maps cannot be configured on dialer 
interfaces. When a connection is made to another router, dialer maps are generated 
dynamically. 


Step 7. Configure the optional parameters on the dialer interface. This is where things like 
dialer idle timeouts and network addressing are placed. 


Example 7-5 illustrates an example configuration that incorporates these seven steps. The important 
thing to notice in this example is the introduction of the logical dialer interface. 
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Example 7-5 Example Dialer Profile Configuration 


Remote_Site#show running-config 
Building contirguration:..... 


Current configuration: 

! 
version 12.0 

service timestamps debug uptime 
service timestamps log uptime 

no service password-encryption 

! 

hostname Remote_Site 

! 

! 
username Headquarters password 0 cisco 
ip subnet-zero 

isdn switch-type basic-—dms100 

! 

interface LoopbackO 

ip address 175.:10.101.1 255.255.255.255 
no ip directed-broadcast 

! 

interface Ethernet0O 

ip address. 175 10.221 255.250.2000 
no ip directed-broadcast 

no keepalive 

! 

interface Serial0O 

no ip address 

no ip directed-broadcast 

shutdown 

no fair-—queue 

clockrate 125000 

! 

interface Seriall 

description PRIMARY LINK TO HQ 
bandwidth 64 

ip. address: 175.10;2002.1, 255.295:255 3292 
no ip directed-broadcast 

! 


interface BRIO 


no ip address 
no ip directed-broadcast 
encapsulation ppp 


isdn switch-type basic-—dms100 
isdn. spidl 61293199371111 
isdn spid2 61293199381111 


no ip classless 
! 


dialer-list 1 protocol ip permit 
! 
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line con 0 

privilege level 15 
logging synchronous 
transport input none 
line aux 0 

line vty 0 4 

login 

! 


end 


! We can verify our configuration by using the show dialer command. Notice here 
that the BRI 0 interface is now bound to the logical dialer interface, dialer 1. 
Remote_Site#show dialer 


BRIO - dialer type = ISDN 


Dial. String Successes Failures Last called Last status 
0 incoming call(s) have been screened. 
0 incoming call(s) rejected for callback. 


BRIO:1 - dialer type = ISDN 

Idle timer (120 secs), Fast idle timer (20 secs) 
Wait for carrier (30 secs), Re-enable (15 secs) 
Dialer state is data link layer up 

Dial reason: ip (s=175.10.23.1, d=175.10.23.2) 


Time until disconnect 111 secs 
Current call connected 00:00:10 
Connected to 6129319833 (6129319833) 


BRIO:2 - dialer type = ISDN 

Idle timer (120 secs), Fast idle timer (20 secs) 
Wait for carrier (30 secs), Re-enable (15 secs) 
Dialer state is idle 


Re-enable (15 secs) 


(30 secs), 


Wait for carrier 


6129319833 OO 00217 successful Default 


Step 4: Configuring Advanced Optional Parameters 


A number of advanced features can be specified using ISDN, including ISDN callback, call screening, 


and PPP authentication. Most of these options apply only to a PPP encapsulated interface. To 
demonstrate this, simply look at the number of PPP options available to us on the BRI interface in 


Example 7-6. 


Example 7-6 Calling Up the Available PPP Options 


R2(config-if)#ppp ? 


authentication Set PPP link authentication method 

bap Set BAP bandwidth allocation parameters 
bridge Enable PPP bridge translation 

callbac k Set PPP link callback option 

chap Set CHAP authentication parameters 
compression Enable PPP Compression control negotiation 
ipcp Set IPCP negotiation options 
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lep PPP LCP configuration 


max—bad-auth Allow multiple authentication failures 
multidlink Make interface multilink capable 

pap Set PAP authentication parameters 

quality Set minimum Link Quality before link is down 
reliable-link Use LAPB with PPP to provide a reliable link 
timeout Set PPP timeout parameters 

use-tacacs Use TACACS to verify PPP authentications 


For example, if you want to use authentication to verify the validity of an incoming ISDN call, you 
must use PPP encapsulation. PPP also can be used to configure dialer callback and multilink, among 
others. Because of the feature available using PPP, and because nearly all real-world ISDN 
configurations use PPP-encapsulated interfaces, you will be using PPP encapsulated BRI interfaces in 
all of the labs. 


The most commonly configured optional parameter involves the use of authentication, which means 
using either PAP or CHAP, as discussed in the sections that follow. 


Example: Authentication Using the Password Authentication Protocol (PAP) 


PAP is a simple method for a remote router to verify the validity of a remote node. The primary 
drawback is that it is not a secure method, meaning that the username and password are sent across 
the ISDN network in plain text and can be seen easily using a protocol analyzer. Because the PAP 
process is sent across the link without encryption, anyone with a protocol analyzer easily can obtain 
this information. PAP also offers no protection against playback and trial-and-error (dictionary or 
brute force) attacks. Because of this, CHAP is the preferred method of authentication. Still, it supplies 
a rudimentary authentication method supported by Cisco. 


To configure PAP, you need to configure four things: 


Step 1. Configure the remote router's username and password in global configuration mode, 
using the username name password password command. The username must match the 
host name that is configured on the remote router exactly, and it is case-sensitive. 


Step 2. Under interface configuration mode, you need to set up PPP encapsulation on the 
ISDN interface using the encapsulation ppp command. 


Step 3. Specify that you are using PAP authentication using the ppp authentication pap 
command. 


Step 4. Specify the local username and password combination that you want to send to the 
remote ISDN router with the ppp pap sent-username username password password 
command. This must match what the remote router has specified in Step 1 for your router. 


Example 7-7 shows the PAP authentication configuration for the calling router, and Example 7-8 
shows the PAP authentication configuration for the called router. 


Example 7-7 Example PAP Authentication Configuration: Router 1 (Calling 
Router) 


ISDN-1#show running-config 
Building configuration... 


Current configuration: 

! 

version 12.0 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
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! 

hostname ISDN-1 

! 

! 

username ISDN-2 password 0 CISCO 

ip subnet-zero 

isdn switch-type basic-—dms100 

! 

! 

! 

interface Loopback0O 

ip address 175.10.101.1 255.255.255.255 
no ip directed-broadcast 

! 

interface Ethernet0 

1p address 175.10..231 255.2593 259.0 
no ip directed-broadcast 

no keepalive 

! 

interface Serial0 

no ip address 

no ip directed-broadcast 
encapsulation frame-relay 

logging event subif-link-status 
logging event dlci-status-—change 

no fair-queue 

clockrate 125000 

! 

interface Seriall 

description PRIMARY LINK TO HQ 
bandwidth 64 

ip.address: 17s .10220021, 255.255.2595 3292 
no ip directed-broadcast 

! 

interface BRIO 
ip address: 175.102.2301 25522593.2502292 
no ip directed-broadcast 
encapsulation ppp 

dialer map ip 175.10.23.2 name ISDN-2 broadcast 6129319833 
dialer-group 1 
isdn switch-type basic-—dms100 
isdn spidl 61293199371111 
isdn spid2 61293199381111 

pep authentication pap 


ppp pap sent-username ISDN-1 password 7 0802657D2A36 
! 


router eigrp 1 
passive-interface BRIO 
network 175.10.0.0 


no auto-summary 
! 


no ip classless 
! 


dialer-list 1 protocol ip permit 
! 

! 

line con 0 

privilege level 15 

logging synchronous 

transport input none 

line aux 0 

line vty 0 4 

login 
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end 


Example 7-8 Example PAP Authentication Configuration: Router 2 (Called 
Router) 


ISDN-2#show running-config 
Building configuration... 


Current configuration: 

! 

version 12.0 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
! 

hostname ISDN-2 

! 


logging buffered 9096 debugging 
! 
username ISDN-1 password 0 CISCO 
ip subnet-zero 
isdn switch-type basic-—dms100 
! 
! 
! 
interface Loopback0O 
ip address: 175. 10.102.1 255.255.255.255 


no ip directed-broadcast 
! 


interface Ethernet0 

ip address: 175.10.161. 255.295.25520 

no ip directed-broadcast 

no keepalive 

! 

interface Serial0 

no ip address 

no ip directed-broadcast 

encapsulation frame-relay 

logging event subif-link-status 
logging event dlci-status-—change 

! 
interface Seriall 

description PRIMARY LINK TO REMOTE SITE 
bandwidth 64 

ip address 175.10.20022 255.255.255.252 
no ip directed-broadcast 

clockrate 125000 

! 
interface BRIO 

ip address: 173.102.2328 2Zos229932503292 
no ip directed-broadcast 

encapsulation ppp 

dialer-group 1 

isdn switch-type basic-—dms100 

isdn spidl 61293198331111 

isdn spid2 61293198461111 

pep authentication pap 


pep pap sent-username ISDN-2 password 7 01302F377824 
! 


no ip classless 
! 
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dialer-list 1 protocol ip permit 
! 

! 

line con 0 

privilege level 15 
logging synchronous 
transport input none 
line aux 0 

line vty 0 4 

login 

! 


end 


In the configuration, the password is encrypted under the BRIO interface. This is done by Cisco |OS 
Software so that anyone passing by your desk cannot obtain the password simply by looking at the 
configuration. This password is encrypted only in the configuration file, and the actual password 
(CISCO) is sent in plain text across the link. 


Example: Authentication Using the Challenge Handshake Authentication Protocol (CHAP) 


CHAP is used in nearly every real-world PPP authentication scheme because it offers better security 
than PAP. CHAP periodically verifies the identity of the remote node and uses the MD5 hash algorithm 
to encrypt the CHAP process. Therefore, Joe Hacker who has put a sniffer on the line will be unable to 
decipher what the password is. CHAP uses a three-way handshake occurring in the following sequence: 


1. The central rite router issues a challenge to the remote router. 
2. The remote router responds to the challenge. 
3. The central site router accepts or rejects the connection. 
Only three configuration steps are required to configure PPP CHAP authentication: 


Step 1. Set the encapsulation type to PPP by on the ISDN interface. 


Step 2. Configure CHAP on the interface using the ppp authentication chap command in 
interface configuration mode. 


Step 3. Configure the username and password of the remote ISDN router(s), using the 
username name password secret in global configuration mode, where name is the host 
name of the remote router and secret is the secret password. The name is case-sensitive and 
must match the remote router's host name exactly (and it is case-sensitive). The secret 
password also must be the same on both routers. If you find that CHAP is failing, one of the 
first things that you should verify is that the username is specified correctly and that both 
routers are using the exact same password. 


Example 7-9 shows the PPP CHAP configuration for Router 1, and Example 7-10 shows the PPP CHAP 
configuration for Router 2. 


Example 7-9 Example PPP CHAP Configuration: Router 1 


ISDN-l#show running-config 

! 

version 12.0 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
! 
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hostname ISDN-1 

| 

! 

ip subnet-zero 

isdn switch-type basic-—dms100 
! 

i] 

! 

interface Ethernet0 

ip address 175.10.2.1 255.255,.255:..0 
no ip directed-broadcast 

! 
interface Serial0O 

no ip address 

no ip directed-broadcast 
shutdown 

no fair-queue 

| 

interface Seriall 

no ip address 

no ip directed-broadcast 
shutdown 

! 
interface BRIO 

ip address: 175.10.23.1 255.255..255:248 
no ip directed-broadcast 


dialer-group 1 

isdn switch-type basic-—dms100 
wsdn. Spidl 61293199371111 
isdn spid2 61293199381111 


! 
no ip classless 
! 
dialer-list 1 protocol ip permit 
! 
i 
line con 0 
privilege level 15 
logging synchronous 
transport input none 
line aux 0 
line vty 0 4 
login 
| 


end 


Example 7-10 Example PPP CHAP Configuration: Router 2 


ISDN-2#show running-config 

| 

version 12.0 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
! 

hostname ISDN-2 

! 

| 
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ip subnet-zero 

isdn switch-type basic-—dms100 
i] 

! 

! 

interface Ethernet0 

ip address 1972.16.11, 255.2552255.0 
no ip directed-broadcast 

| 

interface Serial0 

no ip address 

no ip directed-broadcast 
shutdown 

| 

interface Seriall 

no ip address 

no ip directed-broadcast 
shutdown 

! 

interface BRIO 

ip address: 175:..10.23.2 255.255..255:.248 
no ip directed-broadcast 


dialer-group 1 

isdn switch-type basic-—dms100 
isdn spidl 61293198331111 
isdn spid2 61293198461111 


! 

no ip classless 

! 

dialer-list 1 protocol ip permit 

! 

! 

line con 0 
privilege level 15 
logging synchronous 
transport input none 

line aux 0 

line vty 0 4 
login 

i] 


end 


The important configuration commands for CHAP authentication have been highlighted. 
Example: Authentication Using an Alternative Host Name 


Cisco |OS Software allows you to configure CHAP using a different host name than what the calling 
router's actual host name is. 


When a remote Cisco router connects to either a Cisco or a non-Cisco central router of a different 
administrative control, an Internet service provider (ISP), or a rotary of central routers, it is necessary 
to configure an authentication username that is different from the host name. In this situation, the 
host name of the router is not provided or is different at different times (rotary). Also, the username 
and password that are allocated by the ISP might not be the remote router's host name. In such a 
situation, the ppp chap hostname command is used to specify an alternate username that will be 
used for authentication. 


491 


For example, consider a situation in which multiple remote devices are dialing into a central site. 
Using normal CHAP authentication, the username (which would be the host name) of each remote 
device and a shared secret must be configured on the central router. In this scenario, the 
configuration of the central router can get lengthy and cumbersome to manage; however, if the 
remote devices use a username that is different from their host name, this can be avoided. The 
central site can be configured with a single username and shared secret that can be used to 
authenticate multiple dial-in clients. 


This is done using the ppp chap hostname "alternate-host-name" command: 


ISDN-1(config-if)#ppp chap hostname ? 
WORD Alternate CHAP hostname 


On the called router, you need to configure the username/password combination using the alternate 
host name of the calling router, not the actual host name. Example 7-11 shows the configuration for 


the calling router, and Example 7-12 shows the configuration for the called router. 


Example 7-11 CHAP Alternate Host Name Configuration: Calling Router 


ISDN-1#show running-config 
Building configuration... 


Current configuration: 
! 
version 12.0 
service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
! 
hostname ISDN-1 
! 
username ISDN-2 password cisco 
ip subnet-zero 
isdn switch-type basic-—dms100 
! 
interface Ethernet0 
ip address 172.16.1.1 255.255.2550 
no ip directed-broadcast 
! 
interface Serial0 
no ip address 
no ip directed-broadcast 
shutdown 
no fair-—queue 
| 
interface Seriall 
no ip address 
no ip directed-broadcast 
shutdown 
! 
interface BRIO 
ip address 175.102.2310. 255:255.25592248 
no ip directed-broadcast 


dialer map ip 175.10.23.2 name ISDN-2 broadcast 6129319833 
dialer-group 1 

isdn switch-type basic-—dms100 

isdn. spidl 612931993 71111 

isdn spid2 61293199381111 


os acid selec Senos 
492 


| 
no ip classless 
i] 
dialer-list 1 protocol ip permit 
i] 
! 
line con 0 
privilege level 15 
logging synchronous 
transport input none 
line aux 0 
line vty 0 4 
login 
] 


end 


Example 7-12 CHAP Alternate Host Name Configuration: Called Router 


ISDN-2#show running-config 
Building configuration... 


Current configuration: 

i] 
version 12.0 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
i] 
hostname ISDN-2 

i] 

| 

ip subnet-zero 

isdn switch-type basic-—dms100 
| 

| 

! 

interface Ethernet0O 

ip address 172.16.1.1 255.255.2550 
no ip directed-broadcast 

i] 

interface Serial0 

no ip address 

no ip directed-broadcast 
shutdown 

i] 

interface Seriall 

no ip address 

no ip directed-broadcast 
shutdown 

| 

interface BRIO 

ip address 175.102.2332 259:255.255,,248 
no ip directed-broadcast 


dialer map ip 175.10.23.1 name ISDN-1 broadcast 6129319937 
dialer-group 1 

isdn switch-type basic-—dms100 

isdn spidl 61293198331111 

isdn spid2 61293198461111 
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| 
no ip classless 
! 
dialer-list 1 protocol ip permit 
! 
! 
line con 0 
privilege level 15 
logging synchronous 
transport input none 
line aux 0 
line vty 0 4 
login 
i] 


end 


In this example, the calling router has been authenticated by the called router with a host name of 
FAKENAME, even though the router's actual host name is ISDN-1. You can see this process with the 
debug ppp authentication command in Example 7-13. 


Example 7-13 Calling Router Authentication Verification 


ISDN-l#debug ppp authentication 
PPP authentication debugging is on 
ISDN-l#ping 175.10.23.2 


Type escape sequence to abort. 


Success rate is 80 percent (4/5), round-trip min/avg/max = 40/41/44 ms 
ISDN-1# 

08:38:29: SLINK-3-UPDOWN: Interface BRI0O:1, changed state to up 

08:38:29: SISDN-6-CONNECT: Interface BRIO:1 is now connected to 6129319833 
08:38:29: BRO:1 PPP: Treating connection as a callout 

08:38:30: BRO:1 PPP: Phase is AUTHENTICATING, by both 

08:38:30: BRO:1 CHAP: Using alternate hostname FAKE_NAME 

08:38:30: BRO:1 CHAP: O CHALLENGE id 8 len 30 from "FAKE NAME" 

08:38:30: BRO:1 CHAP: I CHALLENGE id 8 len 27 from "ISDN-2" 

08:38:30: BRO:1 CHAP: Using alternate hostname FAKE_NAME 

08:38:30: BRO:1 CHAP: O RESPONSE id 8 len 30 from "FAKE_NAME" 

08:38:30: BRO:1 CHAP: I SUCCESS id 8 len 4 

08:38:30: BRO:1 CHAP: I RESPONSE id 8 len 27 from "ISDN-2" 

08:38:30: BRO:1 CHAP: O SUCCESS id 8 len 4 

08:38:31: SLINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state 
to up 

ISDN-1# 


PPP PPP Pp 


Note the timeout of the first ICMP ping packet. This was because of the time it took for the ISDN call 
negotiation and connection process. 


Example: Using PPP to Authenticate on Incoming Calls Only—Configuring Unidirectional 
CHAP Authentication 


When two devices normally use CHAP authentication, each side sends out a challenge, to which the 
other side responds and is authenticated by the challenger. Each side authenticates one another 
independently. If you want to operate with non-Cisco routers that do not support authentication by 
the calling router or device, you must use the ppp authentication chap callin command. When 
using the ppp authentication command with the callin keyword, the access server authenticates 
the remote device only if the remote device initiated the call (for example, if the remote device "called 
in"). In this case, authentication is specified on incoming (received) calls only. 494 


As depicted in Table 7-2, if Router 1 initiates a call to Router 2, Router 2 would challenge Router 1, 
but Router 1 would not challenge Router 2. This occurs because the ppp authentication chap callin 
command is configured on Router 1. This is an example of a unidirectional authentication. 


Table 7-2. Unidirectional Authentication 


| Router1 | 1 Router 2 
— a 1 calls Router 2 ---> 
<--- Router 2 challenges Router 1 
Router 1 does not challenge Router 2 because it is configured for one-way 
ieee 


Example: Using PPP Link Quality 


PPP link quality was covered in Chapter 4. It is important to note that this feature also applies to ISDN 
interfaces, as long as they are configured with PPP encapsulation. 


Additional Optional Parameters: Link Quality Monitoring (LQM) 


Link Quality Monitoring (LQM) is available on all serial interfaces running PPP. LQM monitors the link 
quality. If the quality drops below a configured percentage, the router shuts down the link. The 
percentages are calculated for both the incoming and the outgoing directions. The outgoing quality is 
calculated by comparing the total number of packets and bytes sent with the total number of packets 
and bytes received by the destination node. The incoming quality is calculated by comparing the total 
number of packets and bytes received with the total number of packets and bytes sent by the 
destination peer. 


When LQM is enabled, Link Quality Reports (LQRs) are sent in place of keepalives every keepalive 
period. All incoming keepalives are responded to properly. If LQM is not configured, keepalives are 
sent every keepalive period and all incoming LQRs are responded to with an LQR. LQR is specified in 
RFC 1989, "PPP Link Quality Monitoring," by William A. Simpson of Computer Systems Consulting 
Services. To enable LQM on the interface, use the ppp quality percentage command in interface 
configuration mode. 


The percentage argument specifies the link quality threshold. That percentage must be maintained, or 
the link is deemed to be of poor quality and is taken down. The percentages are calculated for both 
incoming and outgoing directions. The outgoing quality is calculated by comparing the total number of 
packets and bytes sent to the total number of packets and bytes received by the peer. The incoming 
quality is calculated by comparing the total number of packets and bytes received to the total number 
of packets and bytes sent by the peer. 


If the link quality percentage is not maintained, the link is deemed to be of poor quality and is taken 
down. The policy implements a time lag so that the link does not bounce up and down. 


Additional Optional Parameters: ISDN Call Screening 


Besides CHAP and PAP authentication, there are alternate ways to authenticate incoming ISDN calls. 
Authentication based on caller 1D provides even greater security than the methods described before 
by authenticating remote clients based not only on user |D and password, but also on dialing location. 
Caller ID allows the initial incoming call from the client to the server to be accepted or rejected based 
on the caller ID message contained in the ISDN setup message. Caller 1D is not available everywhere, 
so be sure to check with the ISDN provider if you want to implement this feature in your netw@grk. 


Only one command is needed to configure ISDN call screening. For Legacy DDR, 


isdn caller remote-number [callback] 


For dialer profil es, 


dialer-caller remote-number [callback] 


The callback option tells the router to terminate the incoming call and call back the router that 
originally placed the call. Callback is covered in the next section. 


Example 7-14 shows how to configure caller screening. 


Example 7-14 Call Screening 


interface BRI 0 
isdn caller 6129319937 


This command can be repeated for each number that will be allowed to dial in. The Cisco 1|OS software 
also allows you to configure "don't care" digits in the remote number, using the letter x. For example, 
to allow all incoming calls from the 952 area code, you would use the isdn caller 952xxxxxxx 
command. You must use one x for each digit that you don't care about. The command isdn caller 
952x is not the same as isdn caller 952xxxxxxx. The first command allows only four-digit numbers 
starting with 952, whereas the second command allows all seven-digit numbers starting with 952. 


Use the debug ISDN event to troubleshoot ISDN call screening. 


Additional Optional Parameters: ISDN Callback 


Callback is a useful feature for networks that want to maintain a central location for all outgoing ISDN 
calls for billing or other business purposes. The callback feature (introduced in Cisco |OS Software 
Release 11.0) allows a remote router to place a call to the central site router requesting that the 
central site router call back the remote router. Then, the central site router disconnects the call and 
places a return call to the remote location. With callback configured, the ISDN bill is reduced at the 
remote sites because actual data transfers occur when the central office router calls back. Example 7- 
15 and 7-16 show the configuration for ISDN callback for the Remote Site and Headquarter routers, 
respectively. 


NOTE 


Callback relies on PPP authentication, so PAP or CHAP authentication must be configured 
for callback to work. 


Example 7-15 ISDN Callback Configuration: Remote Site Router 


Remote_Site#show running-config 
Building configuration: «+ 


Current configuration: 
! 


version 12.0 
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service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
! 
hostname Remote_Site 
i] 
! 
username Headquarters password 0 cisco 
ip subnet-zero 
isdn switch-type basic-—dms100 
! 
! 
! 
interface Ethernet0 
ip address 172.16¢1.1 255.253.259550 
no ip directed-broadcast 
i] 
interface Serial0 
ip address: 175.10.50.1 255225932 592292 
no ip directed-broadcast 
no fair-—queue 
clockrate 125000 
i] 
interface Seriall 
ip address 175.10.1.1 255.255.255.252 
no ip directed-broadcast 
| 
interface BRIO 
ip address 175.10.23 21 255.255:.255:.248 
no ip directed-broadcast 
encapsulation ppp 


dialer map ip 175.10.23.2 name Headquarters broadcast 6129319833 
dialer hold-queue 100 timeout 10 

dialer-group 1 

isdn switch-type basic-—dms100 

isdn spidl 61293199371111 

isdn spidg2 61293199381111 


! 
no ip classless 
! 
dialer-list 1 protocol ip permit 
! 
: 
line con 0 
privilege level 15 
logging synchronous 
transport input none 
line aux 0 
line vty 0 4 
login 
] 


end 


Example 7-16 ISDN Callback Configuration: Headquarters Router 


Headquarters#show running-config 
Building configuration... 
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Current configuration: 

! 

version 12.0 

service timestamps debug uptime 

service timestamps log uptime 

no service password-encryption 

! 

hostname Headquarters 

! 

! 

username Remote_Site password 0 cisco 

ip subnet-zero 

isdn switch-type basic—dms100 

! 

! 

! 

interface Ethernet0O 

ip address 172.16.1.1 255.255.255,.0 
no ip directed-broadcast 

! 

interface Serial0O 

ip address 175.10.50 22 255.255:255).252 
no ip directed-broadcast 

! 

interface Seriall 

ip address L75.10.1.2 255.255.255.252 
no ip directed-broadcast 

clockrate 125000 

! 

interface BRIO 
ip address: 175.10.23.2 255.299.255.248 
no ip directed-broadcast 
encapsulation ppp 


dialer hold-queue 100 
dialer-group 1 

isdn switch-type basic-—dms100 
isdn spidl 61293198331111 
isdn spid2 61293198461111 


! 
no ip classless 
: 
! 


dialer-list 1 protocol ip permit 
! 
! 
line con 0 
privilege level 15 
logging synchronous 
transport input none 
line aux 0 
line vty 0 4 
login 
! 


end 


When an incoming call arrives and the callback router finds a best match configured for callbaee the 


router uses the value configured by the dialer enable-timeout command to determine the length of 
time to wait before making the callback. 


The minimum value of the timer is 1 second; the default value of the timer is 15 seconds. The interval 
set for this feature on this router must be much less than that set for DDR fast call rerouting for ISDN 
(that interval is set by the dialer wait-for-carrier command) on the calling (remote) side. Cisco 
recommends setting the dialer wait-for-carrier timer on the calling side to twice the length of the 
dialer enable-timeout timer on the callback side. In the example, we have set the dialer enable- 
timeout to 5 seconds on the Headquarters router, and the dialer wait-for-carrier timer to 10 seconds 
on the Remote_Site router. 


The dialer callback-server map class configuration command allows the interface to return calls 
when callback successfully is negotiated. The username keyword specifies that the interface is to 
locate the dial string for making the return call by looking up the authenticated host name in a dialer 
map command. 


The dialer map interface configuration command has been modified to include the class keyword 
and the name of the class, as specified in the map-class command. The name keyword is required 
so that when the Remote_Site router dials in, the interface can locate this dialer map statement and 
obtain the dial string for calling back the Remote_Site's router. Example 7-17 illustrates how to utilize 
dialer debugging to verify the callback configuration. 


Example 7-17 Verifying the Callback Configuration 


Remote_Site#debug dialer 
Dial on demand events debugging is on 
Remote_Site#ping 175.10.23.2 


Type escape sequence to abort. 

Sending 5, 100-byte ICMP Echos to 175.10.23.2, timeout is 2 seconds: 
Success rate is 0 percent (0/5) 

Remote_Site# 

00:30:08: BRO DDR: Dialing cause ip (s=175.10.23.1, d=175.10.23.2) 
00:30:08: BRO DDR: Attempting to dial 6129319833 

00:30:08: SLINK-3-UPDOWN: Interface BRI0:1, changed state to up 

00:30:08: SISDN-6-CONNECT: Interface BRIO:1 is now connected to 6129319833 


00:30:09: SLINK-3-UPDOWN: Interface BRI0O:1, changed state to down 


SLINK-3-UPDOWN: Interface BRI0:1, changed state to up 


00:30:14: SISDN-6-CONNECT: Interface BRIO:1 is now connected to 6129319833 
00:30:16: BRO:1 DDR: No callback negotiated 
00:30:16: BRO:1 DDR: dialer protocol up 


DDR: Freeing callback to Headquarters 6129319833 
00:30:16: BRO:1 DDR: Call connected, 4 packets unqueued, 4 transmitted, 0 discar 


00:30:17: SLINEPROTO-5-UPDOWN: Line protocol on Interface BRI0O:1, changed state 


to up 
00:30:20: %ISDN-6—-CONNECT: Interface BRIO:1 is now connected to 6129319833 
Headquarters 


Remote_Site#ping 175.10.23.2 


Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 175.10.23.2, timeout is 2 seconds: 


Success rate is 100 percent (5/5), round-trip min/avg/max = 44/44/44 ms 


Headquarters#show dialer 
BRIO - dialer type = ISDN 


Dial String Successes Failures Last called Last status 
6129319937 4 0 00:00:10 successful 
0 incoming call(s) have been screened. 

0 incoming call(s) rejected for callback. 


BRIO:1 - dialer type = ISDN 

Idle timer (120 secs), Fast idle timer (20 secs) 
Wait for carrier (30 secs), Re-enable (5 secs) 
Dialer state is data link layer up 


Time until disconnect 111 secs 
Connected to 6129319937 (Remote_Site) 


Here, you can see that the first five pings were unsuccessful. This is because of the amount of time 
that it took for the Headquarters router to disconnect the incoming call and then call back the 
Remote_Site router. After this process was completed, the pings were successful. The callback 
process can be seen when issuing the debug dialer command. The show dialer command on the 
Headquarters router clearly shows that the reason for its call was "Callback return call." The debug 
dialer and show dialer commands are useful methods of verifying that the routers are properly 
configured for ISDN callback. 


Additional Optional Parameters: Using PPP Multilink 


Multilink PPP is a feature that allows traffic to be load balanced over multiple WAN links. When 
enabled, the multiple physical links are bonded together and are seen as one logical link. In the case 
of ISDN, you can configure multiple B channels to come up to act as one large traffic pipe. The 
multiple links come up in response to a user-defined threshold using the dialer load-threshold 
command. This threshold can be defined based on inbound or outbound traffic, or either. It is a value 
from 1 to 255, where 1 means that the second BRI channel should come up almost immediately when 
the ISDN link is up, and 255 means that the second BRI channel should come up only when the first 
channel is completely saturated. For example, if you want to have the second B channel bond to the 
first when the load is 50 percent utilized, you would use the command dialer load-threshold 127 
(255 x .50 = 127, after rounding up). Configuring multilink PPP requires the following commands used 
under interface mode: 


encapsulation ppp 
dialer load-threshold load 
ppp multilink 


Example 7-18 shows an example configuration using PPP multilink. 


Example 7-18 PPP Multilink Configuration: 


Remote_Site#show running-config 
Building configuration... 


Current configuration: 

! 

version 12.0 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
! 

hostname Remote_Site 

! 
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| 
username Headquarters password 0 cisco 
ip subnet-zero 
isdn switch-type basic-—dms100 
i] 
| 
! 
interface Loopback0O 
ip address 175.10.101.1 255.255.259.255 
no ip directed-broadcast 
! 
interface Ethernet0 
ip address: 175 .10.2.1. 25592.295%2595.0 
no ip directed-broadcast 
no keepalive 
| 
interface Serial0 
no ip address 
no ip directed-broadcast 
shutdown 
no fair-—queue 
clockrate 125000 
| 
interface Seriall 
description PRIMARY LINK TO HQ 
ip address 175.120.#200..1 255.255.255.252 
no ip directed-broadcast 
! 
interface BRIO 
ip address 175.102.2317 255.255.255.248 
no ip directed-broadcast 


dialer map ip 175.10.23.2 name Headquarters broadcast 6129319833 


dialer-group 1 

isdn switch-type basic-—dms100 
isdn spidl 61293199371111 
isdn spidg2 61293199387111 


i] 
router eigrp 1 
network 175.10.0.0 
no auto-summary 
i] 
no ip classless 
i] 
access-list 101 deny eigrp any any 
access-list 101 permit ip any any 
dialer=list 1. protocol ip list 101 
| 
! 
line con 0 
privilege level 15 
logging synchronous 
transport input none 
line aux 0 
line vty 0 4 
login 
i] 


end 


Here, it is specified that both B channels should be used after the first B channel has exceeded a 
threshold of approximately 10 percent in either outbound or inbound traffic (255 [ts\x .10 is close to 


25), not 25 percent. 


You can verify the multilink PPP configuration by issuing the show dialer command. In Example 7- 
19, the router is made to initiate an ISDN connection by simply pinging the other side of the link. 


Example 7-19 Verifying the Multilink PPP Configuration 


Remote_Site#ping 175.10.23.2 


Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 175.10.23.2, timeout is 2 seconds: 


Success rate is 80 percent (4/5), round-trip min/avg/max = 44/45/48 ms 


Remote_Site#show dialer 
BRIO - dialer type = ISDN 


Dial String Successes Failures Last called Last status 
6129319833 29 62 00:00:06 successful 
0 incoming call(s) have been screened. 

0 incoming call(s) rejected for callback. 


BRIO:1 - dialer type = ISDN 
Idle timer (120 secs), Fast idle timer (20 secs) 
Wait for carrier (30 secs), Re-enable (15 secs) 


Connected to 6129319833 (Headquarters) 
BRIO:2 - dialer type = ISDN 


Idle timer (120 secs), Fast idle timer (20 secs) 
Wait for carrier (30 secs), Re-enable (15 secs) 


You can see that the ISDN connection was made successfully and that the first B channel is indeed a 
multilink member. However, the second B channel still shows that it is idle and was not bonded to the 
first B channel. The reason for this is that the simple pings that traversed the link were not sufficient 
to exceed the 10 percent load that is required in this case. 


To see what the load is for the first B channel, issue the show interface briO 1 command, as 
demonstrated in Example 7-20. 


Example 7-20 Displaying the Load for the First B Channel 


Remote_Site#show interface bri 0 1 
BRIO:1 is up, line protocol is up 
Hardware is BRI 


Encapsulation PPP, loopback not set, keepalive set (10 sec) 
LCP Open, multilink Open 
Last input 00:00:05, output 00:00:05, output hang never 
Last clearing of "Show interface" counters never 
Queueing strategy: fifo 
Output queue 0/40, O drops; input queue 0/75, O drops 
5 minute input rate 1000 bits/sec, 1 packets/sec 
5 minute output rate 1000 bits/sec, 1 packets/sec 
4183 packets input, 2365973 bytes, 0 no buffer 
Received 0 broadcasts, O runts, 0 giants, 0 throttles 
QO input errors, 0 CRC, O frame, O overrun, O ignored, 0 abort 
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4342 packets output, 2396289 bytes, O underruns 

0 output errors, O collisions, 33 interface resets 

0 output buffer failures, O output buffers swapped out 
210 carrier transitions 


You can plainly see that the load on this B channel is only at 3/255. In this configuration, the second 
B channel will come up only after the first B channel has exceeded a load of 25/255, or approximately 
10 percent. 


You will need to create some more traffic to actually bring up both B channels in this configuration. 
You can do this by using the extended ping command, as demonstrated in Example 7-21. 


Example 7-21 Creating Additional Traffic to Bring Up Both B Channels 


Remote_Site#ping 

Protocol. [ip]: 

Target IP address: 175.10.23.2 
Repeat count [5]: 100 
Datagram size [100]: 1500 
Timeout in seconds [2]: 
Extended commands [n]: 

Sweep range of sizes [n]: 

Type escape sequence to abort. 


Sending 100, 1500-byte ICMP Echos to 175.10.23.2, timeout is 2 seconds: 
Po ae a oh Sa en eR ano nS Ona Sen Sea Se ohh 


Success rate is 100 percent (100/100), round-trip min/avg/max = 212/359/428 ms 


Now, issue the same show int bri0 1 command to check the load on the interface, as done in 
Example 7-22. 


Example 7-22 Displaying the Load for Both B Channels 


Remote_Site#show int brid 1 
BRI0O:1 is up, line protocol is up 
Hardware is BRI 


Encapsulation PPP, loopback not set, keepalive set (10 sec) 
LCP Open, multilink Open 
Last input 00:00:04, output 00:00:04, output hang never 
Last clearing of "show interface" counters never 
Queueing strategy: fifo 
Output queue 0/40, O drops; input queue 0/75, O drops 
5 minute input rate 8000 bits/sec, 5 packets/sec 
5 minute output rate 7000 bits/sec, 4 packets/sec 
4452 packets input, 2579061 bytes, O no buffer 
Received 0 broadcasts, O runts, 0 giants, O throttles 
QO input errors, O CRC, O frame, 0 overrun, O ignored, 0 abort 
4611 packets output, 2611177 bytes, O underruns 
QO output errors, O collisions, 33 interface resets 
0 output buffer failures, O output buffers swapped out 
212 carrier transitions 


You can see that the load has reached 27/255, so the second B channel should have been brought up 
to bond with the first B channel. There are a couple of ways to verify that this has indeed happened: 
using the show dialer and the show ppp multilink commands, as demonstrated in Example 7-23. 


Example 7-23 Verifying a Second B Channel with the show dialer comman¢ 


Remote_Site#show dialer 
BRIO - dialer type = ISDN 


Dial String Successes Failures Last called Last status 
6129319835 32 62 OO OOs55 successful 
0 incoming call(s) have been screened. 

0 incoming call(s) rejected for callback. 


BRIO:1 - dialer type = ISDN 

Idle timer (120 secs), Fast idle timer (20 secs) 
Wait for carrier (30 secs), Re-enable (15 secs) 
Connected to 6129319833 (Headquarters) 

BRIO:2 - dialer type = ISDN 


Idle timer (120 secs), Fast idle timer (20 secs) 
Wait for carrier (30 secs), Re-enable (15 secs) 


Connected to 6129319833 (Headquarters) 


Both channels are indeed in use, and the second B channel shows that the dial reason was because of 
a PPP multilink overload. 


Example 7-24 shows how to verify the PPP multilink configuration. 


Example 7-24 Verifying a Second B Channel with the show ppp multilink 
Command 


ISDN-1#show ppp multilink 


Bundle ISDN-2, 2 members, Master link is Virtual-Accessl 

Dialer Interface is BRIO 
0 lost fragments, 0 reordered, 0 unassigned, sequence OxF8/0xF8 rcvd/sent 
0 discarded, 0 lost received, 1/255 load 


Here, both B channels are listed as PPP multilink members. 


In this case, we sent 100 1500-byte ICMP packets across the link. This was enough to bring up the 
secondary B channel. Both B channels were bonded to form one large virtual circuit. 


Step 5: Routing Traffic over ISDN 


As stated previously, there are a number of ways to ensure that traffic is routed over the ISDN 
interface. You want to be able to route traffic over the ISDN link when it is up, but you normally do 
not want this routing traffic to cause it to stay up indefinitely. One important configuration option that 
you should be aware of is the passive-interface routing command. Passive interfaces listen to 
incoming routing updates but will not advertise any routing information out that interface. This is 
particularly effective for dial-on-demand interfaces because you can suppress the routing information 
from causing unnecessary connections. This command is done under the routing process and is valid 
for nearly every routing protocol. Example 7-25 shows an example using EI GRP. 
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Example 7-25 Defining a Passive I nterface 


router eigrp 1 
passive-interface BRIO 
network 175.10.0.0 
no auto-summary 


If the passive-interface BRIO command is not used, the ISDN link continuously would connect as 
routing updates are passed. This assumes that the broadcast keyword is on the dialer map 
statement. The broadcast keyword also will pass any multicast traffic that is often used by routing 
protocols. 


The majority of real-world applications use floating static routes for routing over ISDN so that when 
the primary link fails, the ISDN interface comes up. However, numerous other equally successful 
methods enable you to control routing information over an ISDN network, including the following: 


Floating static routes 
OSPF demand circuit 
Dialer watch 

Backup interface 
Backup load 
Snapshot routing 


Example: Floating Static Routes 


A floating static route is simply a static route with a higher administrative distance than that of the 
routing protocols, which is tagged at the end of the ip route command. Each routing protocol has a 
different administrative distance associated with it. An administrative distance is simply the degree of 
reliability, or cost, of the route. The lower the distance is, the more reliable the routing information is 
for the specified routes. If a router knows about a route from more than one means, the route with 
the lowest administrative distance wins out. Table 7-3 shows the default administrative distances for 
connected interfaces, static routes, and routing protocols. 


Table 7-3. Default Administrative Distances 


| Protocol 


[Connected interface 
(Static route [2 


Enhanced Interior Gateway Routing Protocol 5 

(EIGRP) summary route 

External Border Gateway Protocol (BGP) 20 
e 


Default Administrative 
Distance 


OSPF LILO 
Intermediate System-to-Intermediate System 

iS 
(1S-1S) 
Routing Information Protocol (RIP) 120 
Exterior Gateway Protocol (EGP) 140 


External EIGRP 170 
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Internal BGP 200 
Unknown 255 


A static route becomes floating when it is assigned a higher AD than that of the routing protocols. It is 
called "floating" because when a route known through some other means goes away, the floating 
static route "floats" to the top and is used by the router. For example, if you use the command ip 
route 10.1.1.0 255.255.255.0 BRI 0 200, you have manually assigned an AD of 200 to this route. 
The router routes packets to 10.1.1.0/24 through the BRI 0 interface only if it knows of no other way 
to reach this subnet. This is useful when you want to use the ISDN network to route traffic only if the 
primary link has failed. This is the most common real-world method used to configure ISDN to back 
up a primary link failure. Figure 7-6 shows a simple network between the two routers Cheech and 
Chong. In this case, Frame Relay is used as the primary communication link between the two routers, 
with the ISDN link being used as a backup method only. 


Figure 7-6. Floating Static Route Example 


( Ethermet 


Frame Relay 
Chong Co SS 


In this scenario, you want to maintain connectivity between users on the Ethernet segments between 
the two locations. Example 7-26 shows the configuration for the proper use of floating static routes in 
this scenario. 


Example 7-26 Floating Static Route Configuration 


Cheech#show running-config 
Building configuration: .. 


Current. configuration: 
! 
version 11.2 
no service password-encryption 
no service udp-small-servers 
no service tcp-small-servers 
! 
hostname Cheech 
! 
enable password cisco 
! 
username Chong password 0 cisco 
isdn switch-type basic-—dms100 
! 
interface Loopback0O 
ip address 175 .10.2.2 255.255.255:.0 


506 


i] 
interface Ethernet0 
ip address 175.1022.) 255.255::255:..0 
no keepalive 
no mop enabled 
i] 
interface Serial0O 
ip address 175).10.123..1..255.255..2551.0 
encapsulation frame-relay 
frame-relay map ip 175.10.123.2 300 broadcast 
! 


interface Seriall 


no ip address 

shutdown 

| 

interface BRIO 

ip address 175..10.23.1 255.255.255:.0 
encapsulation ppp 

isdn spidl 61293199371111 

isdn spid2 61293199381111 

dialer map ip 175.10.23.2 broadcast 6129319833 
dialer-group 1 

no fair-—queue 

pep authentication chap 

! 

router eigrp 1 

passive-interface BRIO 

network 175.10.0.0 

no auto-summary 

| 


ip classless 


| 
dialer-list 1 protocol ip permit 
| 
line con 0 
exec-timeout 0 0 
privilege level 15 
logging synchronous 
line aux 0 
line vty 0 4 
password cisco 
login 
! 


end 


Chong#show running-config 
Building ‘contiguration. . : 


Current. configuration: 

! 

version 11.2 

no service password-encryption 
no service udp-small-servers 
no service tcp-small-servers 

! 

hostname Chong 

! 

enable password cisco 

! 

username Cheech password 0 cisco 
isdn switch-type basic-—dms100 
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| 
interface Loopback0O 

ip address 1275.10.33 255.255..255:..0 
! 
interface Ethernet0 

bp address 175:10.35e3 255.255.2550 
! 
interface Serial0 

no ip address 

encapsulation frame-relay 

no fair-queue 

| 
interface Serial0.1 point-to-point 

ip address “175 10.123:.2 255.255.2595.0 
frame-relay interface-dlci 200 

| 
interface Serial0.2 point-to-point 

ip address: 175.110.1342 255% 255.255°. 252 
shutdown 

frame-relay interface-dlci 400 

! 

interface Seriall 

no ip address 

shutdown 

! 

interface BRIO 

ip address 175, 10s23.2 255.255 .255'.0 
encapsulation ppp 

isdn spidl 61293198331111 

isdn spid2 61293198461111 
dialer map ip 175.10.23.1 broadcast 6129319937 
dialer-group 1 

no fair-—queue 

pep authentication chap 

| 

router eigrp 1 

passive-interface BRIO 

network 175.10.0.0 

no auto-summary 

| 

no ip classless 


! 
dialer-list 1 protocol ip permit 
! 
line con 0 
exec-timeout 0 0 
privilege level 15 
logging synchronous 
line aux 0 
line vty 0 4 
password cisco 
login 
| 


end 


You have made the BRIO interfaces passive under the EIGRP processes. This was needed to keep the 
routing updates from initiating calls and keeping up the link indefinitely. Because the dialer list 
specifies all IP packets as interesting, EIGRP multicast updates would have brought the ISDN link up. 
An alternative to using the passive-interface command is to use a more restrictive dialer list that 
denies EIGRP packets. 
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Example: OSPF Demand Circuit 


As the name implies, an OSPF demand circuit enables the ISDN link to work through the OSPF 
protocol. This topic was introduced in Chapter 12, demand circuits suppress the OSPF hello packets 
from traversing the ISDN link, and ISDN calls initiate only after a logical topology change. Without 
this feature, these hello packets can keep the link up indefinitely. This feature is enabled through the 
following single interface command: 


ISDN_Router#config term 
ISDN_Router (config) #int brid 
ISDN_Router(config-if) #ip ospf demand-circuit 


This seems simple enough, right? In most situations, it is. However, keep in mind that when a change 
in the OSPF link-state database occurs, an ISDN call is made. Therefore, in certain situations, such as 
when you are redistributing other protocols into OSPF, you must be careful in how you implement the 
redistribution, to avoid routing loops that will cause these link-state changes to occur constantly. You 
will see an example of this soon in the advanced practice labs when you need to do more than simply 
add the ip ospf demand-circuit command to make this work properly. Figure 7-7 shows the 
reference network that we will use to illustrate the proper configuration for setting up the OSPF 
demand circuit. 


Figure 7-7. Example OSPF Demand Circuit Configuration 


Remote site 64 K Point-to-point link (primary) Headquarters 


Example 7-27 shows the configuration for both the Headquarters and Remote Site routers. 


Example 7-27 OSPF Demand Circuit Configuration 


Remote_Site#show running-config 
Building configuration... 


Current configuration: 

! 

version 12.0 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
! 

hostname Remote_Site 

! 

! 

username Headquarters password 0 cisco 
ip subnet-zero 

isdn switch-type basic-—dms100 

! 

! 

! 
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interface LoopbackO 

ip address 175.10.10121 255.255.259.255 
no ip directed-broadcast 

i] 

interface Ethernet0 

ip address: 1752.10.21 2552259522550 
no ip directed-broadcast 

no keepalive 

! 

interface Serial0 

no ip address 

no ip directed-broadcast 

shutdown 

no fair-—queue 


! 
interface Seriall 

description PRIMARY LINK TO HQ 

ip: address: 175 .10s20021. 25512959 .2599'.202 
no ip directed-broadcast 


interface BRIO 

ip address 175.10.23.1 255.255.255::248 
no ip directed-broadcast 

encapsulation ppp 


dialer map ip 175.10.23.2 name Headquarters broadcast 6129319833 
dialer-group 1 

isdn switch-type basic-—dms100 

isdn. Spidl 612931993 71111 

isdn spid2 61293199381111 


no ip classless 

! 
dialer-list 1 protocol ip permit 
! 

! 

line con 0 

privilege level 15 
logging synchronous 
transport input none 
line aux 0 

line vty 0 4 

login 

! 


end 


Headquarters#show running-config 
Building configuration... 


Current configuration: 

} 

version 12.0 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
| 
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hostname Headquarters 
! 


logging buffered 9096 debugging 

! 
username Remote_Site password 0 cisco 

ip subnet-zero 

isdn switch-type basic-—dms100 

! 

! 

l 

interface Loopback0O 

ip address 175.10.102.1 255.255.255.255 
no ip directed-broadcast 

| 

interface Ethernet0 

1p address: 175.1051.) 255.2559: 259.0 

no ip directed-broadcast 

no keepalive 

! 

interface Serial0 

no ip address 

no ip directed-broadcast 

shutdown 

! 
interface Seriall 

description PRIMARY LINK TO REMOTE SITE 
ip address 175.110.2002 255.255.255.252 
no ip directed-broadcast 

clockrate 64000 


interface BRIO 
ip address: 175. L0.23.2 255.255.255.248 
no ip directed-broadcast 
encapsulation ppp 
dialer-group 1 
isdn switch-type basic-—dms100 
isdn spidl 61293198331111 
isdn spid2 61293198461111 
! 
router ospf 1 
network 175.10.0.0 0.0.255.255 area 0 
! 
no ip classless 
! 
dialer-list 1 protocol ip permit 
! 
! 
line con 0 
privilege level 15 
logging synchronous 
transport input none 
line aux 0 
line vty 0 4 
login 
| 


end 


The ip ospf demand circuit configuration command in interface mode tells the router to not send 
hello packets out that interface. Without it, the OSPF hellos will keep the link up. Example 7-28 shows 


the output from the show ip ospf interface bri0 command. 
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Example 7-28 Using the show ip ospf interface Command 


Remote_Site#show ip ospf interface bri0 
BRIO is up, line protocol is up (spoofing) 
Internet Address 175.10.23.1/29, Area 0 
Process ID 1, Router ID 175.10.101.1, Network Type POINT_TO_POINT, Cost: 9999 
Configured as demand circuit. 
Run as demand circuit. 
DoNotAge LSA allowed. 
Transmit Delay is 1 sec, State POINT_TO_POINT, 
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 
Hello due in 00:00:01 


You can see that OSPF has formed a neighbor adjacency with the Headquarters router and is 
suppressing the hello packets for the BRI O interface. 


In this network, the primary link is a 64-kbps point-to-point circuit. As you will learn in the OSPF 
section of this book, it is generally a good idea to explicitly state the actual bandwidth of each 
interface that OSPF has been enabled on, which is why you used the bandwidth 64 command on the 
Serial 1 interface of each router. This is because the metric used in OSPF is cost, which is calculated 
as 100,000,000/bandwidth. 


Unless you actually state what the bandwidth is for the serial interface, OSPF assumes that it is a full 
T1 and incorrectly gives the interface an OSPF cost of 64. For ISDN interfaces, OSPF assumes that the 
link is 64 kbps and assigns it a cost of 1562. This can be seen with the show ip ospf interface briO 
command, as demonstrated in Example 7-29. 


Example 7-29 Assigning a Cost to an ISDN Interface in an OSPF Environment 


Remote_Site#show ip ospf int bri0O 
BRIO is up, line protocol is up (spoofing) 
Internet Address 175.10.23.1/29, Area 0 


Configured as demand circuit. 

Run as demand circuit. 

DoNotAge LSA allowed. 

Transmit Delay is 1 sec, State POINT_TO_POINT, 

Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 
Hello due in 00:00:03 

Neighbor Count is 1, Adjacent neighbor count is 1 


Notice that the OSPF hello packets are being suppressed and will not be sent over the ISDN network. 


The problem here is that now OSPF has assigned a cost of 1562 to both the Serial 1 and BRI 
interfaces. It now sees these links as equal-cost path, and traffic is load balanced across both links. 
This causes the ISDN link to stay up indefinitely. To remedy this, it is usually a good idea to assign an 
artificially high OSPF cost to the BRI interfaces, ensuring that traffic is routed over this link only after 
the alternate paths are down. 


In this example, a cost of 9999 has been assigned to the ISDN link by issuing the ip ospf cost 9999 
command. This actual cost that you implement doesn't really matter, but it needs to be high enough 
that OSPF will not prefer the backup ISDN link. 
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Under normal circumstances, the routing table should look like Example 7-30. 


Example 7-30 Testing the OSPF Demand Circuit Configuration 


Remote_Site#show ip route 

Codes: C —- connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 

D -— EIGRP, EX —- EIGRP external, O —- OSPF, IA - OSPF inter area 

Nl - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 

El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 

i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U —- per-user static route, o -— ODR 


Gateway of last resort is not set 


175.10.0.0/16 is variably subnetted, 6 subnets, 4 masks 
175.10.200.0/30 is directly connected, Seriall 
175.10.1.0/24 [110/1572] via 175.10.200.2, 00:00:39, Seriall 
175.10.2.0/24 is directly connected, Ethernet0 
175.10.23.0/29 is directly connected, BRIO 
175.10.101.1/32 is directly connected, Loopback0O 
175.210.1702 :1/32 [LlO/1563) via 175.10.200.2, 00*00:39, Sériall 
Remote_Site#ping 175.10.1.1 


Oy COO 


Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 175.10.1.1, timeout is 2 seconds: 


Success rate is 100 percent (5/5), round-trip min/avg/max = 16/18/20 ms 


Now, you will administratively shut down the Serial 1 interface and verify that you still have 
connectivity to the Headquarters router, as demonstrated in Example 7-31. 


Example 7-31 Testing the ISDN Backup with the Primary Link Shut Down 


Remote_Site#conft t 

Enter configuration commands, one per line. End with CNTL/Z. 
Remote_Site(config) #int sl 

Remote_Site(config-if) #shut 

Remote_Site (config-if) # 

3d03h: SLINK-3-UPDOWN: Interface BRI0:1, changed state to up 
Remote_Site(config-if) #end 

Remote_Site# 

3d03h: SISDN-6-CONNECT: Interface BRIO:1 is now connected to 6129319833 

3d03h: SLINK-5-CHANGED: Interface Seriall, changed state to administratively down 
n 
3d03h: *SYS-5-CONFIG_I: Configured from console by console 

3d03h: SLINEPROTO-5-UPDOWN: Line protocol on Interface BRIO:1, changed state to 
up 
3d03h: SLINEPROTO-5-UPDOWN: Line protocol on Interface Seriall, changed state to 
down 
Remote_Site# 
3d03h: SISDN-6-CONNECT: Interface BRI0O:1 is now connected to 6129319833 Headquarters 
Remote_Site#sho ip route 

Codes: C —- connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 

D -— EIGRP, EX —- EIGRP external, O —- OSPF, IA - OSPF inter area 

Nl - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 

El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 

i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 

U —- per-user static route, o —- ODR 


Gateway of last resort is not set 
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175.10.0.0/16 is variably subnetted, 6 subnets, 3 masks 
175.0021.0/24 [110/10009) via 175.120.2332, 00:00:06, BRIO 
175.10.2.0/24 is directly connected, Ethernet0 
175.10.23.2/32 is directly connected, BRIO 
175.10.23.0/29 is directly connected, BRIO 
175.10.101.1/32 is directly connected, Loopback0O 
175.10.102.1/32 [110/10000] via 175.10.23.2, 00200:06, BRIO 
Remote_Site#ping 175.10.1.1 


EY EF 


Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 175.10.1.1, timeout is 2 seconds: 


Success rate is 100 percent (5/5), round-trip min/avg/max = 40/43/44 ms 


Because OSPF detected a topology change in the network, it initiated a connection. If you issue the 
show dialer command as demonstrated in Example 7-32, you can see that the reason for the ISDN 


call was IP traffic to the destination of 224.0.0.5. This is the multicast address used in OSPF. 


Example 7-32 show dialer Command Reveals the Reason for an ISDN Call 


Remote_Site#show dialer 
BRIO - dialer type = ISDN 


Dial String Successes Failures Last called Last status 
6129319833 44 62 OO OLe 5:5 successful 
0 incoming call(s) have been screened. 

OQ incoming call(s) rejected for callback. 


BRIO:1 - dialer type = ISDN 

Idle timer (120 secs), Fast idle timer (20 secs) 
Wait for carrier (30 secs), Re-enable (15 secs) 
Dialer state is data link layer up 


Time until disconnect 49 secs 
Connected to 6129319833 (Headquarters) 


BRIO:2 - dialer type = ISDN 

Idle timer (120 secs), Fast idle timer (20 secs) 
Wait for carrier (30 secs), Re-enable (15 secs) 
Dialer state is idle 


When the primary link is restored, the ISDN connection tears down after the dialer idle timeout period 
has occurred. It can be easy to create routing loops in your network, especially when multiple routes 
are being redistributed. It is important to use filtering to ensure that these loops do not cause 
unnecessary ISDN connections. 


Example: Dialer Watch 


Dialer watch became a feature with Cisco |OS Software Release 11.3(2)T. It works by having the |OS 
"watch" the routing table to keep track of a number of user-defined routes. When one or more of the 
routes in the dialer watch list are removed from the routing table, an ISDN connection is initiated. The 
speed and effectiveness of implementing dialer watch depends on the convergence times and 
characteristics of the routing protocol used. EIGRP works best and normally is implemented with 
dialer watch, although dialer watch also is supported using OSPF and IGRP. 


Dialer watch uses the ISDN network as a backup means to provide reliable connectivity between 
remote locations. Dialer watch monitors the routing table and initiates calls when the primary link fails 
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and one of the routes defined in the dialer watch list is removed from the routing table. It does this in 
the following sequence: 


1. When a watched route is deleted, dialer watch checks for at least one valid route for any of the 
watched IP addresses defined. 


2. If there is no valid route, the primary line is considered down and unusable. 


3. If there is a valid route for at least one of the defined watched IP addresses and the route is 
pointing to an interface other than the backup interface configured for dialer watch, the 
primary link is considered up. For example, if a site remote site has two Frame Relay PVCs to 
its headquarters, and one of the PVC's goes down, traffic still can be routed over the 
secondary PVC rather than over the ISDN link. 


4. |f the primary link goes down, the routing protocol immediately notifies the dialer watch 
process, and the secondary link (in this case, the ISDN line) is brought up. 


5. After the secondary link is up, the primary link is checked again at the expiration of each idle 
timeout. 


6. If the primary link remains down, the idle timer is reset. 


If the primary link comes back up, the secondary link is disconnected. A disable timer can be set to 
delay the disconnection of the secondary link. 


For the network in Figure 7-8, you will back up the connection to network 175.10.1.0/24 and to the 
Headquarters loopback address, ensuring connectivity despite a Frame Relay outage. 


Figure 7-8. Network Topology for Dialer Watch Configuration Example 


Remote Site Point-to-point link (primary) Headquarters 


Example 7-33 shows the configuration for using dialer watch. 


Example 7-33 Dialer Watch Configuration 


Remote_Site#show running-config 
Building configuration... 


Current configuration: 

! 

version 12.0 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
| 
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hostname Remote_Site 

! 

! 

username Headquarters password 0 cisco 
ip subnet-zero 

isdn switch-type basic-—dms100 

! 

! 

! 

interface Loopback0O 

ip address 175.10.101.1 255.255.255.255 
no ip directed-broadcast 

! 

interface Ethernet0 

ip address 175 +102.2.1 255e295. 2596.0 

no ip directed-broadcast 

no keepalive 

! 
interface Serial0 

no ip address 

no ip directed-broadcast 

shutdown 

no fair-—queue 

clockrate 125000 

! 
interface Seriall 

description PRIMARY LINK TO HQ 

ip address 175.10 .200.1. 255.255.255.252 
no ip directed-broadcast 

! 
interface BRIO 

ip address: 17511022321 255.2552255¢248 
no ip directed-broadcast 

encapsulation ppp 

dialer map ip 175.10.23.2 name Headquarters broadcast 6129319833 
dialer map ip 175.10.102.1 name Headquarters broadcast 6129319833 
dialer map ip 175.10.1.0 name Headquarters broadcast 6129319833 
dialer watch-group 1 

dialer-group 1 

isdn switch-type basic-—dms100 

isdn spidl -61293199371111 


isdn spid2 61293199381111 
! 


router eigrp 1 

network 175.10.0.0 

no auto-summary 

! 

no ip classless 

! 

access-list 101 deny eigrp any any 
access-list 101 permit ip any any 
dialer watch=list. 1 ap LvVs.10.102:1. 255.255.255.250 
Gialer wateh=list 1 ap 175.210.1020 255.295.2550 
dialer=list 1 protocol ip list 101 

! 

! 

line con 0 

privilege level 15 

logging synchronous 

transport input none 

line aux 0 

line vty 0 4 

login 
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end 


Headquarters#show running-config 
Building configuration: .. 


Current configuration: 

! 
version 12.0 

service timestamps debug uptime 
service timestamps log uptime 

no service password-encryption 

! 

hostname Headquarters 

! 

! 

username Remote_Site password 0 cisco 
ip subnet-zero 

isdn switch-type basic-—dms100 

! 

! 

! 

interface Loopback0O 

ip address: 175+10.,102.1 255.2553 259.255 
no ip directed-broadcast 

! 

interface Ethernet0 

ip address: 175 .102.12.1. 255229542550 
no ip directed-broadcast 

no keepalive 

| 

interface Serial0 

no ip address 

no ip directed-broadcast 

shutdown 

! 

interface Seriall 

description PRIMARY LINK TO REMOTE SITE 
ip address: 175.10.200.2 255.255.255.252 
no ip directed-broadcast 

clockrate 125000 

! 

interface BRIO 

ip address: 1775. L0:23'.2- 255.255.255.248 
no ip directed-broadcast 
encapsulation ppp 

dialer-group 1 

isdn switch-type basic-—dms100 

isdn spidl 61293198331111 


isdn spid2 61293198461111 
! 


router eigrp 1 
network 175.10.0.0 
no auto-summary 
! 

no ip classless 
! 

dialer-list 1 protocol ip permit 
! 

l 

line con 0 
privilege level 15 
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logging synchronous 
transport input none 
line aux 0 

line vty 0 4 

login 

! 


end 


If any of the routes defined in the dialer-watch list still exists in the routing table, the primary 
interface is considered to be up, and the ISDN call will not initiate. |n this example, both the routes to 
the Headquarters Ethernet segment and the loopback address must disappear from the routing table 
before dialer watch will cause the router to make a call. Using a loopback address is an effective way 
to use dialer watch because this interface is always up. If you specified only the Ethernet network in 
the dialer watch list, ISDN calls would be made whenever the Ethernet interface went down. This is 
not a desired result because the primary link might still be up; if the Ethernet is down, it will be just 
as unreachable through the backup link as it would be through the primary connection. In this 
example, you could have just as easily chosen only the Headquarters loopback network in the dialer 
watch list. Instead, both the Ethernet and loopback networks were used in the dialer watch list to 
illustrate that all routes being watched must no longer be in the routing table for dialing to occur. 


CAUTION 


The networks defined in the dialer watch list must match the network and subnet masks 
in the routing table exactly. For example, if the routing table shows 175.10.0.0/16 and 
your configuration lists dialer watch-list 1 ip 175.10.0.0 255.255.255.0, the dialer 
watch process will be incapable of detecting that 175.10.0.0/16 is no longer in the 
routing table. 


Example: Backup Interface 


Using the backup interface command is another effective way of using ISDN to back up a primary 
link failure. This command works by keeping track of the link status of the primary interface and 
initiating an ISDN connection only when the interface status of the primary interface changes from up 
to down. 


NOTE 


Some documentation states that the backup interface will come up when only the line 
protocol of the primary interface goes from up to down. This is not the case. The actual 
interface must be down, and the line protocol must be down also. You will see an 
example of where it will not work when the interface is administratively down and the 
line protocol is down. 


Using the backup interface method is not as common as using floating static routes because the only 
way to test that the ISDN link is working is by actually taking down the primary link physically. 


Configuring the backup interface requires only one command: 


Router (config-if) #backup interface bri 0 


This is performed under the primary link's interface, not under the ISDN interface. An optional 
parameter that you should be aware of is the backup delay command. This configuration command 
allows you to determine the time that the ISDN link should wait after detecting a primary Mn areas 


before initiating a call, as well as the amount of time that the backup link should wait before tearing 
down this call after the primary link has been restored. This is useful when the primary link 
experiences frequent, short outages, and you do not want the ISDN router to initiate a call every time 
this happens. This is done with the command sequence in Example 7-34, again done under the 
primary link's interface configuration mode. 


Example 7-34 Example Backup Configuration 


interface SerialO 


ip address 175.10.123.1 255.255.255.0 
encapsulation frame-relay 
frame-relay map ip 175.10.123.2 300 broadcast 


Here, the primary link is the Frame Relay connection on Serial 0, and the backup link is the ISDN link 
on BRI 0. The ISDN link will wait 5 seconds after before calling, after the Serial 0 interface goes from 
up to down, and it will wait 60 seconds before ending the call after the Serial O interface goes from 
down to up. The backup delay is configured in seconds and can be a value from 0 to 4,294,967,294 
seconds for both delay times. Configuring the delays is an optional parameter; if omitted, the ISDN 
link will come up instantly upon the primary links failure, and the call will terminate instantly upon 
restoration of the primary link. 


Set the delays to ensure that fast bouncing circuits do not start the ISDN call. Bouncing circuits will 
create havoc with link-state routing protocols, especially OSPF. 


When configuring the ISDN link as backup interface, the BRI 0 interface status changes from up, line 
protocol up (spoofing), to standby mode, line protocol down, as demonstrated in Example 7-35. 


Example 7-35 ISDN Interface Status When Using the Backup I nterface 
Configuration 


Cheech#show int brid 
BRIO is standby mode, line protocol is down 
Hardware is BRI 
Internet address is 175.10.23.1/24 
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255 
Encapsulation PPP, loopback not set 
Last input 00:19:42, output 00:19:42, output hang never 
Last clearing of "show interface" counters 1d04h 
Queueing strategy: fifo 
Output queue 0/40, O drops; input queue 0/75, 0 drops 
5 minute input rate 0 bits/sec, 0 packets/sec 
5 minute output rate 0 bits/sec, 0 packets/sec 
21175 packets input, 88385 bytes, 0 no buffer 
Received 4 broadcasts, O runts, 0 giants, 0 throttles 
OQ input errors, 0 CRC, O frame, 0O overrun, O ignored, 0 abort 
21175 packets output, 89187 bytes, O underruns 
0 output errors, O collisions, 2 interface resets 
0 output buffer failures, O output buffers swapped out 
3 carrier transitions 


This interface remains in standby mode and will be unusable until the primary link fails. 


Figure 7-9 shows the example network to reference for your backup interface configuration. 


Figure 7-9. Network Topology for Backup Interface Configuration Example 
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Example 7-36 shows an example backup interface configuration. 


Example 7-36 Backup Interface Configuration 


Cheech#show running-config 
Building configuration... 


Current configuration: 

i 

version 11.2 

no service password-encryption 
no service udp-small-servers 


no service tcp-small-servers 
! 


hostname Cheech 

! 

enable password cisco 

! 

username Chong password 0 cisco 

isdn switch-type basic-—dms100 

! 

interface Loopback0O 

ip address 175),10.2.2 259.255.2550 
! 

interface Ethernet0 

ip address 175.10.22.1 255.255 .255:.0 
no keepalive 

no mop enabled 

! 

interface Serial0 

backup delay 5 60 

backup interface BRIO 

ip address 175 v10.123.1 255.255.2550 
encapsulation frame-relay 
frame-relay map ip 175.10.123.2 300 broadcast 
! 

interface Seriall 

no ip address 

shutdown 

! 
interface BRIO 

ip: address: 175,10.23 ol. .255.255.255:.0 
encapsulation ppp 


Frame Relay 


Cheech 
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isdn spidl 61293199371111 
isdn spid2 61293199381111 
dialer map ip 175.10.23.2 broadcast 6129319833 
dialer-group 1 

no fair-—queue 

pep authentication chap 

! 
router eigrp 1 

network 175.10.0.0 

no auto-summary 

! 

ip classless 

! 


dialer-list 1 protocol ip permit 
! 

line con 0 
exec-timeout 0 0 
privilege level 15 
logging synchronous 
line aux 0 

line vty 0 4 
password cisco 
login 

! 


end 


Chong#show running-config 
Building configuration... 


Current configuration: 

! 

version 11.2 

no service password-encryption 
no service udp-small-servers 
no service tcp-small-servers 

! 

hostname Chong 

! 

enable password cisco 

! 

username Cheech password 0 cisco 
isdn switch-type basic-—dms100 
! 

interface Loopback0O 


ip address 1275.10.33: 255.255..2551..0 
! 


interface Ethernet0 

ip address: 175: 10.3563. 255.255.2550 
! 

interface Serial0O 

no ip address 

encapsulation frame-relay 

no fair-queue 

! 

interface Serial0.1 point-to-point 

ip address 175.120.1232 255.255.255'.0 
frame-relay interface-dlci 200 

! 

interface Seriall 

no ip address 

shutdown 

! 
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interface BRIO 

ip: address: 1715 +10.238.32 2os<.2553.2590:/0 
encapsulation ppp 

isdn spidl 61293198331111 
isdn spid2 61293198461111 
dialer idle-timeout 9999 
dialer-group 1 

no fair-—queue 

pep authentication chap 

! 
router eigrp 1 

network 175.10.0.0 

no auto-summary 

! 
no ip classless 

! 
dialer-list 1 protocol ip permit 
! 

line con 0 

exec-timeout 0 0 
privilege level 15 
logging synchronous 

line aux 0 

line vty 0 4 

password cisco 

login 

! 


end 


No special configuration command was needed in the Chong router, and the BRIO interface was not 
made passive under the EIGRP routing process. Normally, when you fail to do this, the EIGRP process 
keeps the ISDN link up indefinitely, but because it is configured as a backup interface, it will not call 
unless the Serial 0 interface goes down. 


When testing the backup interface scenario, it is important to realize that it will not work simply by 
administratively shutting down the serial interface on the Cheech router. A backup interface 
connection will be made only when the primary link's interface is down, not administratively down. 
However, if you had implemented logical subinterfaces in the Cheech router, using Serial 0.1 for the 
Frame Relay connection to Chong, you could have configured the backup interface commands on the 
Serial 0.1 interface. In this case, you could have shut down the physical Serial 0 interface, and the 
ISDN backup connection would have worked because the Serial 0.1 interface would have gone from 
up to down (not administratively down). But because you configured the physical serial interface with 
the backup command in the previous case, you need to actually unplug the Frame Relay connection 
from the router (or power down the Frame Relay switch in the lab) to initiate the ISDN call. 


Example 7-37 shows Cheech's routing table before the Frame Relay outage. Example 7-38 shows the 
same routing table after the Frame Relay outage. 


Example 7-37 Cheech's Routing Table Before Frame Relay Outage 


Cheech#show ip route 
Codes: C —- connected, S - static, I - IGRP, R - RIP, M —- mobile, B —- BGP 
D — EIGRP, EX —- EIGRP external, O —- OSPF, IA - OSPF inter area 
Nl - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U - per-user static route, o — ODR 


Gateway of last resort is not set 


175.10.0.0/24 is subnetted, 7 subnets 529 


175.10.35:.0 [90/2195456) va 175.110.1232; 00205:07,;, Serialo 
175.10.5.0 [90/2323456] via 175.10.123.2, 00:05:07, Seriald 
175.10.3.0 [90/2297856] via 175.10.123.2, 00:05:07, Seriald 
175.10.2.0 is directly connected, Loopback0O 

175210.23.0 [90/41024000)]) via 175.10.123:2, O00s04:41, Serialo 
175.10.22.0 is directly connected, Ethernet0 

175.10.123.0 is directly connected, Serial0 

Cheech# ping 175.10.35.3 


(ee ae = eo 


Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 175.10.35.3, timeout is 2 seconds: 


Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms 


Example 7-38 Cheech's Routing Table After Frame Relay Outage 


Cheech#show ip route 
Codes: C -— connected, S - static, I - IGRP, R - RIP, M —- mobile, B —- BGP 
D — EIGRP, EX —- EIGRP external, O —- OSPF, IA - OSPF inter area 
Nl - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U - per-user static route, o — ODR 


Gateway of last resort is not set 


175.10.0.0/16 is variably subnetted, 7 subnets, 2 masks 
175.10.35.0/24 [90/40537600] via 175.10.23.2, 00:00:12, BRIO 
175.10.5.0/24 [90/40665600] via 175.10.23.2, 00:00:12, BRIO 
175:10.3:.0/724 [90/40640000]. via 175.10.23.2, 00700212, BRIO 
175.10.2.0/24 is directly connected, Loopback0O 
175.10.23.2/32 is directly connected, BRIO 
175.10.23.0/24 is directly connected, BRIO 
175.10.22.0/24 is directly connected, Ethernet0 

Cheech#ping 175.10.35.3 


Cd 1 OEY US 


Type escape sequence to abort. 

Sending 5, 100-byte ICMP Echos to 175.10.35.3, timeout is 2 seconds: 
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/41/44 ms 
Cheech# 


After the Frame Relay connection was unplugged from the Cheech router, it dialed into Chong after 
waiting 5 seconds. After restoring the connection, the ISDN call ended after 60 seconds. Again, these 
timers are user-configurable. 


Example: Using the backup load Command 


Using the backup interface command is also helpful in that, when the primary link becomes overly 
utilized, an ISDN call can be initiated to provide more bandwidth using the backup load command on 
the primary link's interface. It also provides a way to configure the routers to make an ISDN 
connection to back up a failed primary link. A major advantage to using this method to initiate ISDN 
calls is that it works over any routed or routing protocol. This is bandwidth on demand, not backup. 
But backup load does work in conjunction with backup interface, as follows: 


A Cisco IOS interface is placed into backup mode by applying the backup interface command: 


e The backup interface interface configuration command specifies the interface that is to act as 
the backup. 
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e The backup load command specifies the traffic threshold at which the backup interface is to 
be activated and deactivated. 

e The backup delay command specifies the amount of time that is to elapse before the backup 
interface is activated or deactivated after a transition on the primary interface. 


Backup interfaces traditionally lock the backup interface into backup state so that it is unavailable for 
other use. Dialer profiles eliminates this lock and allows the physical interface to be used for multiple 
purposes. Floating static route DDR design also eliminates this lock on the dialer interface. 


Using the configuration in Example 7-39, BRI 0 is activated only when serial interface 1/0 (the 
primary line) goes down. The backup delay command configures the backup connection to activate 
30 seconds after serial interface 0 goes down and to remain activated for 60 seconds after the serial 
interface 1/0 comes up. 


Example 7-39 Configuration Options Using Backup Delay 


interface serial 1/0 
ip address 172.20.1.4 255.255.255.0 
backup interface bri 2/0 
backup delay 30 60 


Using the configuration in Example 7-40, BRI 2/0 is activated only when the load on Serial 0 (the 


primary line) exceeds 75 percent of its bandwidth. The backup line is deactivated when the aggregate 
load between the primary and backup lines is within 5 percent of the primary line's bandwidth. 


Example 7-40 Configuration Options Using Backup Load 


interface serial 1/0 
ip address 172.20.1.4 255.255.255.0 
backup interface bri 2/0 
backup load 75 5 


Using the configuration in Example 7-41, BRI 2/0 is activated only when serial interface 1/00 goes 
down or when traffic exceeds 25 percent. If serial interface 1/0 goes down, 10 seconds will elapse 
before BRI 0 becomes active. When serial interface 1/0 comes up, BRI 2/0 remains active for 60 
seconds. If BRI 2/0 is activated by the load threshold on serial interface 1/0, BRI 2/0 is deactivated 
when the aggregate load of serial interface 1/0 and BRI 2/0 returns to within 5 percent of the 
bandwidth of serial interface 1/0. 


Example 7-41 Using the Backup Load Configuration 


interface serial 1/0 
ip address 172.20.1.4 255.255.255.0 
backup interface bri 2/0 
backup load 25 5 
backup delay 10 60 


Note the difference between PPP multilink and backup load. In PPP multilink, the dialer-load threshold 
value was specified as a value from 1 to 255. In backup load, the number specified to bring up the 
backup connection is given as a true percentage (0 to 100). 


Example: Snapshot Routing 


Snapshot routing works on the client/server principle in which one router (usually the headquarters 
router) is designated as the snapshot server, and one or more routers (remote sites) are the snapshot 
clients. The clients connect to the server at specific times, called the active period, to obtain Eagir 


routing information from the server. The term snapshot gets its name from the fact that when the 
clients' active time expires, the ISDN call disconnects but the clients retain a "snapshot" of the routing 
entries. During the time that the ISDN line is idle, termed the quiet period, these routing entries 
remain frozen into the clients' routing tables. When the quiet period ends, the clients dial into the 
snapshot server to obtain the latest routing information. The quiet and active periods are configurable 
(5 to 1000 minutes for the active time, and 8 to 100,000 minutes for the quiet period). 


Because link-state protocols rely on the use of periodic hellos to retain neighbor adjacency, snapshot 
routing can be used only with link-state protocols, such as IGRP and RIP for IP, RIP for |PX, and RTMP 
for AppleTalk. 


Snapshot Client Configuration 


Configuring snapshot routing is relatively simple. For the client router, only two commands are 
needed in interface config mode. The first one is as follows: 


router (config-if)#snapshot client active-time quiet-time [suppress-statechange-updates ] 
[dialer] 


This command sets the active and quiet periods, in minutes. The suppress-statechange-updates 
command option disables the exchange of routing updates each time that the link comes up because 
of any additional traffic. The default is that routing information is exchanged whenever the ISDN link 
is up for any reason. The dialer option is used to tell the client router to go ahead and dial into the 
snapshot server in the absence of regular traffic, and to point to the appropriate dialer map specified 
in Step 2. 


The second required command is as follows: 


router (config-if)# dialer map snapshot sequence-number name name dial-string 


This command defines the dialer map that includes the snapshot server router to call for routing 
updates. 


A common point of confusion occurs when using the help (the ?) the feature in this command, when 
a protocol address is asked for when the sequence number is really needed. Consider the 
configuration in Example 7-42. 


Example 7-42 dialer map snapshot Confusion Illustration 


Cheech#conft t 

Cheech (config) #int brid 

Cheech (config-if) #dialer map snapshot ? 
N Protocol specific address 


It appears here that |OS is looking for a specific protocol address, when, in fact, only a sequence 
number is required. Sequence numbers are used to identify a dialer map and prioritize the sequence 
(a number from 1 to 254) in which the client calls the server routers, if there are multiple server 
routers. If only one server router exists, any sequence number will do. The point here is to remember 
to input only a number from 1 to 254, not to try to put in any kind of Layer 3 address. 


Snapshot Server Configuration 


This one is easy because only one command is needed: 


Router (config-if)#snapshot server active-timer [dialer] 
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The active-timer specified in this command must match the same value that was placed on the client 
router. 


Example Snapshot Configuration 


In the simple network in Figure 7-10, Frame Relay is used as the primary communication link between 


the two sites, and snapshot routing is used to exchange routing information between the two locations 
so that connectivity will remain through the ISDN link in the case of a Frame Relay outage. We made 
the BRI interfaces passive to eliminate the routing updates from triggering a call. 


Figure 7-10. Snapshot Network Reference 
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Example 7-43 illustrates the proper snapshot configuration. 


Table 7-4. Snapshot Client Router Configuration 


Cheech#show running-configuration 
no service password-encryption 
no service udp-small-servers 
no service tcp-small-servers 

! 

hostname Cheech 

! 

enable password cisco 

! 

username Chong password 0 cisco 

isdn switch-type basic-—dms100 

! 

interface Loopback0O 

ip address: L75.10.2.2 255.255..255...0 

! 

interface Ethernet0 

ip address. L/os10.22.1 255,..2559..255'.0 
no keepalive 

no mop enabled 

! 
interface Serial0 

ap address: 175: 10,123.) 255125993299 .0 
encapsulation frame-relay 
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frame-relay map ip 175.10.123.2 300 broadcast 
! 

interface Seriall 

no ip address 

shutdown 

i] 

interface BRIO 

ip address 175.10.23.1) 255.255.2550 
encapsulation ppp 

isdn sprdl 612931993 71111 

isdn spid2 61293199381111 


dialer map ip 175.10.23.2 broadcast 6129319833 
dialer-group 1 

no fair-—queue 

pep authentication chap 

! 

router igrp 1 

network 175.10.0.0 

| 


ip classless 
i] 


dialer-list 1 protocol ip permit 
i] 

line con 0 
exec-timeout 0 0 
privilege level 15 
logging synchronous 
line aux 0 

line vty 0 4 
password cisco 
login 

! 


end 


Chong#show running-configuration 
no service password-encryption 
no service udp-small-servers 
no service tcp-small-servers 

| 
hostname Chong 

! 
enable password cisco 

! 
username Cheech password 0 cisco 
isdn switch-type basic-—dms100 

! 

interface Loopback0O 

ip address: 1753 1023:3 255.2995 290:2.0) 
! 

interface Ethernet0 

ip address: 275.160.3503 255..255.255:..0 
| 

interface Serial0O 

no ip address 

encapsulation frame-relay 

no fair-—queue 

i] 

interface Serial0.1 point=to=point 
tp address: 17/5310 ,123 2 255. 29593290 +0 


frame-relay interface-dlci 200 
! 
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interface Seriall 

no ip address 

shutdown 

! 

interface BRIO 

ip address: L/5.10.2322 255.2255:255.20 
encapsulation ppp 

isdn spidl 61293198331111 

isdn spid2 61293198461111 
dialer-group 1 


no fair-queue 

pep authentication chap 
' 

router igrp 1 

network 175.10.0.0 

! 

no ip classless 

! 


dialer-list 1 protocol ip permit 
! 

line con 0 
exec-timeout 0 0 
privilege level 15 
logging synchronous 
line aux 0 

line vty 0 4 
password cisco 
login 

! 


end 


An important note here is that we have not made the BRIO interfaces passive under the IGRP process. 
This is needed so that routing traffic will pass over the ISDN link and the snapshot routing process will 
keep this line from coming up needlessly. To verify that the routers do connect during the active 
period and that routing traffic is being passed, you can issue the show dialer and show snapshot 


commands, as demonstrated in Example 7-44. 


Example 7-43 Verifying Router Connections During Active Periods and 


Passing of Routing Traffic 


Cheech#show dialer 
BRIO - dialer type = ISDN 


Dial String Successes Failures 
6129319833 85 0 
0 incoming call(s) have been screened. 


BRIO:1 - dialer type = ISDN 

Idle timer (120 secs), Fast idle timer (20 secs) 
Wait for carrier (30 secs), Re-enable (15 secs) 
Dialer state is data link layer up 

Dial reason: snapshot 

Time until disconnect 6 secs 

Connected to 6129319833 (Chong) 


BRIO:2 - dialer type = ISDN 
Idle timer (120 secs), Fast idle timer (20 secs) 
Wait for carrier (30 secs), Re-enable (15 secs) 


Last called 
OOsS1Os22 


Last status 
successful 
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Dialer state is idle 
Cheech#show dialer 


BRIO - dialer type = ISDN 


Dial String Successes Failures Last called Last status 
6129319333 85 0 OOS 10226 successful 
0 incoming call(s) have been screened. 


BRIO:1 - dialer type = ISDN 

Idle timer (120 secs), Fast idle timer (20 secs) 
Wait for carrier (30 secs), Re-enable (15 secs) 
Dialer state is data link layer up 


Time until disconnect 


The reason for this ISDN connection was to exchange snapshot routing information. Based on the 
previous example, these exchanges should take place every 20 minutes, for a length of 10 minutes 
each. In real-world applications, you might want to increase the quiet time period because causing 
the link to come up every 20 minutes might seem a bit excessive and costly. 


The show snapshot command can be used to verify that the snapshot processes are working 
properly and to show which snapshot options are being applied, as demonstrated in Example 7-45. 


Example 7-44 Verifying Snapshot Processes and Applied Options 


Cheech#show snapshot 
BRIO is up, line protocol is up Snapshot client 
Options: dialer support 


Length of active period: 10 minutes 
Length of quiet period: 20 minutes 
Length of retry period: 13 minutes 


For dialer address 1 
Current state: active, remaining/exchange time: 8/2 minutes 
Connected dialer interface: 
BREOe1 
Updates received this cycle: ip 


Only IP routes are being passed, and you can verify that this router has been configured as a client 
using dialer information, with the configured active and quiet periods, along with the retry period. The 
retry period defaults to the configured active period plus 3 minutes. 


To test that routing over the ISDN link works in the event of a Frame Relay outage, unplug the Frame 
Relay connection from the Cheech router. Example 7-46 and 7-47 show the routing table before and 


after the Frame Relay connection was unplugged. 


Example 7-45 Routing Table Before Frame Relay Outage 


Cheech#show ip route 
Codes: C -— connected, S - static, I - IGRP, R - RIP, M —- mobile, B —- BGP 
D — EIGRP, EX —- EIGRP external, O —- OSPF, IA - OSPF inter area 
Nl - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U - per-user static route, o -— ODR 


Gateway of last resort is not set 


175.10.0.0/24 is subnetted, 6 subnets 529 


175.10.35.0 [100/8576] via 175.10.123.2, 00:00:04, SerialO 
175.10.3.0 [100/8976] via 175.10.123.2, 00:00:04, SerialO 
175.10.2.0 is directly connected, Loopback0O 

175.10.23.0 is directly connected, BRIO 

175.10.22.0 is directly connected, Ethernet0O 

175.10.123.0 is directly connected, Serial0 

Cheech# ping 175.10.35.3 


CX Cy CY 1 A ial 


Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 175.10.35.3, timeout is 2 seconds: 


Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/8 ms 


Example 7-46 Routing Table After a Frame Relay Outage 


Cheech#show ip route 

Codes: C —- connected, S - static, I - IGRP, R - RIP, M —- mobile, B —- BGP 

D — EIGRP, EX —- EIGRP external, O —- OSPF, IA - OSPF inter area 

Nl - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 

El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 

i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U - per-user static route, o —- ODR 


Gateway of last resort is not set 


175.10.0.0/16 is variably subnetted, 6 subnets, 2 masks 
175210.35.00/24 [LO00/158350] via 175.10.23.2;, 00*00200, BRIO 
175.10.3.0/24 [100/158750] via 175.10.23.2, 00:00:00, BRIO 
175.10.2.0/24 is directly connected, Loopback0O 
175.10.23.2/32 is directly connected, BRIO 
175.10.23.0/24 is directly connected, BRIO 
175.10.22.0/24 is directly connected, Ethernet0 

Cheech#ping 175.10.35.3 


CC eS 


Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 175.10.35.3, timeout is 2 seconds: 


Success rate is 100 percent (5/5), round-trip min/avg/max = 40/43/44 ms 


It took only a couple seconds for the routing to converge to the ISDN link. When the Frame Relay link 
was restored, traffic again was routed over this link quickly. 
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The "Big show" and "Big D" for Troubleshooting ISDN 


We will now cover some of the ISDN troubleshooting techniques that will aid in discovering and 
isolating common ISDN issues, as well as some tips to help you properly configure ISDN. 


The "Big show" for ISDN 


The following list includes some of the most useful commands when trying to isolate |SDN-related 
problems, and this should be among the first things done to verify whether the ISDN link is working 
properly. 


show isdn status Command 


This command tells you whether your router is properly talking to the carrier's ISDN switch. It tells 
you the ISDN switch type that has been configured for each interface, as well as information about 
the SPID status and active layer calls. Example 7-48 shows an example where the router's BRI 


interface is properly configured and connected to the ISDN switch. 


Example 7-47 show isdn status Command Output 


Cheech#show isdn status 
The current ISDN Switchtype = basic-—dms100 
ISDN BRIO interface 


Layer 2 Status: 
TEI = 104, State 
TEI = 113, State 
Spid. Status: 
TEI 104, ces = 1, state = 5(init) 
spidl configured, no LDN, spidl sent, spidl valid 
Endpoint ID Info: epsf = 0, usid = 0, tid = B 
TEI 113, ces = 2, state = 5(init) 
spid2 configured, no LDN, spid2 sent, spid2 valid 
Endpoint ID Info: epsf = 0, usid = 1, tid =B 
Layer 3 Status: 


__—s«1 Active Layer 3 Call(s) —’ Shows that a connection has been made to another 
Activated dsl 0 CCBs = 2 
CCB: callid=0x0, sapi=0, ces=1, B-chan=0 


CCB: callid=0x802A, sapi=0, ces=1, B-chan=1 
Total Allocated ISDN CCBs = 2 


MULTIPLE FRAME ESTABLISHED 
MULTIPLE FRAME ESTABLISHED 


Depending on the router model and |OS version, it might be necessary to reset the BRI interface for 
the router's interface to properly connect to the ISDN switch. To illustrate this, watch what happens 
when we entered the bswitch type and SPID information into a Cisco 2503 running IOS version 11.2 
(20) in Example 7-49. 


Example 7-48 Verifying ISDN Layer 2 Status 


ISDN_Router#show isdn status 
The current ISDN Switchtype = basic-—dms100 
ISDN BRIO interface 


531 


Layer 1 Status: 
ACTIVE 
Layer 2 Status: 
TEI = 88, State = MULTIPLE_FRAME_ ESTABLISHED 
Spid Status: 
TEI 88, ces = 1, state = 5(init) 
spidl configured, no LDN, spidl sent, spidl valid 
Endpoint ID Info: epsf = 0, usid = 0, tid = B 
TEI Not Assigned, ces = 2, state = 1(terminal down) 
spid2 configured, no LDN, spid2 NOT sent, spid2 NOT valid 
Layer 3 Status: 
0 Active Layer 3 Call(s) 
Activated dsl 0 CCBs = 0 
Total Allocated ISDN CCBs = 0 


Here, you can see that SPID 1 was accepted, but SPID 2 was not. After verifying that the SPID 
information is indeed correct, we reset the BRI interface by issuing the shutdown/no shutdown 
commands. Example 7-50 shows the results. 


Example 7-49 Resetting the BRI Interface 


ISDN_Router (config) #int briO 
ISDN_Router (config-—if) #shut 
ISDN_Router(config-if)#no shut 
ISDN_Router (config-if) # 
SLINK-5-CHANGED: Interface BRIO, changed state to administratively down 
SLINK-3-UPDOWN: Interface BRIO:1, changed state to down 
SLINK-3-UPDOWN: Interface BRI0:2, changed state to down 
SLINK-3-UPDOWN: Interface BRIO, changed state to up 
ISDN Router (config-if) #end 
SISDN-6-LAYER2UP: Layer 2 for Interface BRO, TEI 88 changed to up 
SISDN-6-LAYER2UP: Layer 2 for Interface BRO, TEI 97 changed to up 
SSYS-5-CONFIG_I: Configured from console by console 
Blue-R8#show isdn status 
The current ISDN Switchtype = basic-—dms100 
ISDN BRIO interface 
Layer 1 Status: 
ACTIVE 
Layer 2 Status: 
TEI = 88, State = MULTIPLE_FRAME_ ESTABLISHED 
TEI 97, State MULTIPLE FRAME ESTABLISHED 
Spid Status: 
TEI 88, ces = 1, state = 5(init) 
spidl configured, no LDN, spidl sent, spidl valid 
Endpoint ID Info: epsf = 0, usid = 0, tid =B 
TEI 97, ces = 2, state = 5(init) 
spid2 configured, no LDN, spid2 sent, spid2 valid 
Endpoint ID Info: epsf = 0, usid = 1, tid =B 
Layer 3 Status: 
0 Active Layer 3 Call(s) 
Activated dsl 0 CCBs = 1 
CCB: callid=0x0, sapi=0, ces=1, B-chan=0 
Total Allocated ISDN CCBs = 1 


After the interface was reset, both SPIDS were properly talking to the ISDN switch and were shown 
as valid. One of the first things that should be done to verify connectivity to the ISDN provider's 
switch is to issue the show isdn status command. If the SPIDs will not come active following an 
interface reset, power-reset the router. This has proven to get the correct signaling from the switch 
when all else fails. 
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show interface bri0 Command 


This command is useful in showing the general status of the ISDN interface. In general, after the 
ISDN circuit is connected to the interface and it is administratively enabled, it will be spoofing. 
Spoofing is the state in which the 1OS makes the interface pretend to be up so that the routing table 
can point to this interface to pass traffic. Example 7-51 demonstrates the output from this command. 


Example 7-50 Checking the Status of the ISDN Interface 


Cheech#show int bri0 
BRIO is up, line protocol is up (spoofing) 
Hardware is BRI 
Internet address is 175.10.23.1/30 
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255 
Encapsulation PPP, loopback not set 
Last input 00:00:01, output 00:00:01, output hang never 
Last clearing of "Show interface" counters 00:00:02 
Queueing strategy: fifo 
Output queue 0/40, O drops; input queue 0/75, O drops 
5 minute input rate 0 bits/sec, 0 packets/sec 
5 minute output rate 0 bits/sec, 0 packets/sec 
1 packets input, 4 bytes, 0 no buffer 
Received 0 broadcasts, O runts, O giants, O throttles 
input errors, O CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
packets output, 4 bytes, O underruns 
output errors, 0 collisions, O interface resets 
output buffer failures, 0 output buffers swapped out 
carrier transitions 


So Oe - @ 


If you want to see the status of each individual B channel, you can issue the show interface briO 1 


2 command, as demonstrated in Example 7-52. 


Example 7-51 Checking the Status of the Individual B Channels on the ISDN 


Interface 


Cheech#show interface brid 1 2 
BRIO:1 is down, line protocol is down 
Hardware is BRI 
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255 
Encapsulation PPP, loopback not set, keepalive set (10 sec) 
LCP Closed, multilink Closed 
Closed: IPCP, CDPCP 
Last input 00:00:07, output 00:00:05, output hang never 
Last clearing of "show interface" counters 00:00:49 
Queueing strategy: fifo 
Output queue 0/40, O drops; input queue 0/75, O drops 
5 minute input rate 0 bits/sec, 0 packets/sec 
5 minute output rate 0 bits/sec, 0 packets/sec 
9 packets input, 144 bytes, O no buffer 
Received 9 broadcasts, O runts, O giants, O throttles 
OQ input errors, 0 CRC, 0 frame, O overrun, O ignored, 0 abort 
10 packets output, 152 bytes, O underruns 
OQ output errors, O collisions, O interface resets 
0 output buffer failures, 0 output buffers swapped out 
1 carrier transitions 
BRI0:2 is down, line protocol is down 
Hardware is BRI 
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255 
Encapsulation PPP, loopback not set, keepalive set (10 sec) 
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LCP Closed, multilink Closed 
Closed: IPCP,; CDPCP 
Last input 00:10:44, output 00:10:44, output hang never 
Last clearing of "show interface" counters 00:00:53 
Queueing strategy: fifo 
Output queue 0/40, O drops; input queue 0/75, O drops 
5 minute input rate 0 bits/sec, 0 packets/sec 
5 minute output rate 0 bits/sec, 0 packets/sec 

0 packets input, 0 bytes, O no buffer 

Received 0 broadcasts, O runts, O giants, O throttles 
input errors, O CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
packets output, 0 bytes, O underruns 
output errors, 0 collisions, 0 interface resets 
output buffer failures, 0 output buffers swapped out 
carrier transitions 


eer ei ei =) 


In this example, both B channels are down (the ISDN line is idle). 


show dialer Command 


This command enables you to determine which B channels are connected, as well as determine the 


destination number and the time until the call will tear down. It is also useful in that it shows the 


reason that each call was made (in the calling router only). Example 7-53 demonstrates the output 


generated from this command. 


Example 7-52 show dialer Command Output 


Cheech#show dialer 
BRIO - dialer type = ISDN 


Dial. Strang Successes Failures Last called Last status 
6129319833 31, 0 OOS00.15 successful 
0 incoming call(s) have been screened. 


BRIO:1 - dialer type = ISDN 

Idle timer (120 secs), Fast idle timer (20 secs) 
Wait for carrier (30 secs), Re-enable (15 secs) 
Dialer state is physical layer up 


Time until disconnect 104 secs 


BRIO:2 - dialer type = ISDN 

Idle timer (120 secs), Fast idle timer (20 secs) 
Wait for carrier (30 secs), Re-enable (15 secs) 
Dialer state is physical layer up 


Time until disconnect 104 secs 


In this example, both B channels are in use and are connected to a router named Chong. The first call 
was made as a result of an IP packet from 175.10.23.1 destined for 175.10.23.2 (which was allowed 
in the dialer-list). The second B channel was connected as a result of multilink bonding. (PPP multilink 


was configured on this particular BRIO interface. ) 
show isdn active Command 


As demonstrated in Example 7-54, this command is useful in showing the number of calls that are 
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currently active, as well the number dialed and the idle time before disconnect. 


Example 7-53 show isdn active Command Output 


ISDN-1#show isdn active 


History table has a maximum of 100 entries. 
History table data is retained for a maximum of 15 Minutes. 


Call Calling Called Remote Seconds Seconds Seconds Charges 
Type Number Number Name Used Left Idle Units/Currency 
Out 6129319833 ISDN-2 6 0 0 


The "Big D" for ISDN 


Included here are some of the most useful debugging commands to use when trying to determine the 
cause of any ISDN anomalies. Among the most common problems are calls not connecting, calls that 
never hang up, and dialer interfaces that continuously connect, hang up, and then connect again. 


debug isdn q.921 Command 


Personally, we have never found this debug command to be particularly useful, except when 
troubleshooting SPID problems. The debug isdn q.921 command shows what is happening at Layer 
2. The output in Example 7-55 shows what happens when the SPID's are improperly configured. 


Example 7-54 debug q.921 Command Output 


debug isdn q921 


19:27:31: TX -> IDREQ ri = 19354 ai = 127 dsl = 0 
19:27:33: TX -> IDREQ ri = 1339 ai = 127 dsl = 0 

19:27:35: TX -> IDREQ ri = 22764 ai = 127 dsl = 0 
19:27:37: TX -> IDREQ ri = 59309 ai = 127 dsl = 0 
19:27:39: TX -> IDREQ ri = 25214 ai = 127 dsl = 0 
19:27:41: TX -> IDREQ ri = 35423 ai = 127 dsl = 0 
19:27:43: TX -> IDREQ ri = 12368 ai = 127 dsl = 0 
19:27:45: TX -> IDREQ ri = 13649 ai = 127 dsl = 0 
19:27:47: TX -> IDREQ ri = 35426 ai = 127 dsl = 0 
19:27:49: TX -> IDREQ ri = 12419 ai = 127 dsl = 0 
19:27:51: TX -> IDREQ ri = 14516 ai = 127 dsl = 0 
19:28:04: TX -> IDREQ ri = 50165 ai = 127 dsl = 0 
19:28:06: TX -> IDREQ ri = 838 ai = 127 dsl = 0 

19:28:08: TX -> IDREQ ri = 14247 ai = 127 dsl = 0 
19:28:34: TX -> IDREQ ri = 45592 ai = 127 dsl = 0 
19:28:36: TX -> IDREQ ri = 54169 ai = 127 dsl = 0 
19:28:38: TX -> IDREQ ri = 3370 ai = 127 dsl = 0 

19:29:09: TX -> IDREQ ri = 57291 ai = 127 dsl = 0 
19:29:11: TX -> IDREQ ri = 56444 ai = 127 dsl = 0 
19:29:13: TX -> IDREQ ri = 42045 ai = 127 dsl = 0 
19:29:44: TX -> IDREQ ri = 59406 ai = 127 dsl = 0 


535 


19:29:46: TX => 
1932903483: TX => 
Lo 3019s. “EX. => 
1928305215 "Ex => 
Lg 3O0E233 IX => 
192302545. TX => 
19230 2562: "TX => 
L9s830rSe's TX => 
1931224 TX => 
L9SS1t26: “TX => 


DREQ ri = 26863 ai = 127 dsl = 
DREQ ri = 63456 ai = 127 dsl 
ri = 30177 ai = 127 dsl 
ri = 54258 ai = 127 dsl = 
ri = 4883 ai = 127 dsl = 0 
ri = 17476 ai 127 dsl = 0 
ri = 34949 ai = 127 dsl = 0 
ri = 4310 ai = 127 dsl =0 

DREQ ri = 7735 ai = 127 dsl = 0 

DREQ ri = 424 ai = 127 dsl = 0 


Oe oS 2 


ll 


HHHHHHHHHH 
BO ae eo 
AHDAADD 
Eel eh eh ee i 
Om Cn Om Om Ome) 


The router is sending identification requests (IDREQ) to the ISDN switch but is not receiving a 
response from the switch. If a SPID is incorrectly configured in the router, this debug command also 
shows that it was rejected. 


debug isdn events Command 


Debugging Q.931 can be useful when you want to check the status of incoming and outgoing ISDN 
calls. This debug command displays the call setup and teardown process, and it can give some 
insight on what any problems with these processes might be. Example 7-56 demonstrates sample 


output from this command. 


Example 7-55 debug isdn events Command Output 


BRIO: Dialing cause: BRIO: ip PERMIT 

BRIO: Attempting to dial 6968900 TX -> SETUP dsl = 0 pd = 8 callref = 0x01 Bearer 
Capability i = 0x8890218F Channel ID i = 0x83 

Called Party Number i = 0x80, '6968900' RX RELEASE dsl = 0 pd = 8 callref = 0x01 RX 
Router# 


You can see that interesting traffic tried to initiate an ISDN connection, but the remote router did not 
answer the call (this is seen by the RX RELEASE) output. Normally, this problem is caused by a 
misconfigured dialing number or SPID. In this case, the dialing number was misconfigured. 


debug dialer Command 


This is probably the single most important debug command available. It can give insight to a number 
of things, such as the reason calls are initiated, whether the remote router is responding, and, in 
many cases, why calls fail. Example 7-57 demonstrates the output that appears when the router 


configuration is missing a dialer map or dialer string command. 


Example 7-56 debug dialer Command Output 


ISDN-l#debug dialer 


lwld: BRO DDR: Dialing cause ip (s=175.10.23.1, d=175.10.23.2) 
lwld: BRO DDR: No dialer string, dialing cannot occur 
lwld: BRO DDR: Dialing cause ip (s=175.10.23.1, d=175.10.23.2) 
lwld: BRO DDR: No dialer string, dialing cannot occur 
lwld: BRO DDR: Dialing cause ip (s=175.10.23.1, d=175.10.23.2) 
lwld: BRO DDR: No dialer string, dialing cannot occur 
lwld: BRO DDR: Dialing cause ip (s=175.10.23.1, d=175.10.23.2) 
lwld: BRO DDR: No dialer string, dialing cannot occur 
lwld: BRO DDR: Dialing cause ip (s=175.10.23.1, d=175.10.23.2) 
lwld: BRO DDR: No dialer string, dialing cannot occur 


Unlike many other debug outputs, the debug dialer gives some intuitive information about the 
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Perhaps the most useful information that we can obtain is the reason that calls initiate, showing 
which packets actually pass through the dialer list to make outgoing calls. For example, say that you 
are seeing the ISDN line connecting constantly, even though you have a restrictive dialer list in place. 
Example 7-58 shows the resulting output from the debug dialer command with this set of 


circumstances. 


Example 7-57 debug dialer Command Output 


ISDN-l#debug dialer 


lwld: BRO DDR: Attempting to dial 6129319833 

lwld: SLINK-3-UPDOWN: Interface BRIO:1, changed state to up 

lwld: sISDN-6-CONNECT: Interface BRIO:1 is now connected to 6129319833 
lwld: sLINK-3-UPDOWN: Interface Virtual-Accessl, changed state to up 
lwld: Vil DDR: dialer protocol up 


lwld: *SYS-5-CONFIG_I: Configured from console by console 

lwld: sLINEPROTO-5-UPDOWN: Line protocol on Interface BRIO0O:1, changed state to up 

lwld: sLINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1l, changed 
state to ‘up 


The highlighted output type shows that the reason for the ISDN call is an IP packet with a source of 
175.10.23.1 to a destination of 224.0.0.10. If you did your homework, you know that the 224.0.0.10 
is a multicast address that EIGRP uses to announce routes. Therefore, EIGRP updates are triggering 
the call. To remedy this, make sure that the BRI interface is listed as passive under the EIGRP 
process, or deny all EIGRP packets in your dialer list. 


Some extensions to the debug dialer command are the debug dialer packets and events 
commands. debug dialer packets will give you some in depth insight on packets that are interesting 
and those that are not. debug dialer events will show you some additional information about the 
call setup and teardown process. 


debug ppp authentication Command 


Example 7-59 reflects a situation in which the BRI interface constantly goes up and down and no 
traffic will traverse the link. 


Example 7-58 Authentication Failure Symptoms 


Cheech#ping 175.10.23.2 


Type escape sequence to abort. 

Sending 5, 100-byte ICMP Echos to 175.10.23.2, timeout is 2 seconds: 
Success rate is 0 percent (0/5) 
Cheech# 

SLINK-3-UPDOWN: Interface BRIO: 
SLINK-3-UPDOWN: Interface BRIO: 
SLINK-3-UPDOWN: Interface BRIO: 
SLINK-3-UPDOWN: Interface BRIO: 
SLINK-3-UPDOWN: Interface BRIO: 
SLINK-3-UPDOWN: Interface BRIO: 
SLINK-3-UPDOWN: Interface BRIO: 
SLINK-3-UPDOWN: Interface BRIO: 
SLINK-3-UPDOWN: Interface BRIO: 
SLINK-3-UPDOWN: Interface BRIO: 
Cheech# 


changed state to up 
changed state to down 
changed state to up 
changed state to down 
changed state to up 
changed state to down 
changed state to up 
changed state to down 
changed state to up 
changed state to down 


x 


x 


x 


x 


~ 


x 


x 


x 


PRPPPPP PPR 
~ 


x 
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A prime suspect for this type of behavior is PPP authentication failure. Example 7-60 shows the 
output from the debug ppp authentication command to indicate the symptoms of this problem. 


Example 7-59 PPP Authentication Debugging 


Cheech#debug ppp authentication 
SLINK-3-UPDOWN: Interface BRIO:1, changed state to up 
BRO:1 PPP: Treating connection as a callout 


BRO:1 PPP: Phase is AUTHENTICATING, by both 

BRO:1 CHAP: O CHALLENGE id 17 len 27 from "Cheech" 
BRO:1 CHAP: I CHALLENGE id 17 len 26 from "Chong" 
BRO:1 CHAP: O RESPONSE id 17 len 27 from "Cheech" 


BRO:1 CHAP: I FAILURE id 17 len 21 msg is "MD compare failed" 
SLINK-3-UPDOWN: Interface BRIO:1, changed state to down 


As you can see, the MD compare failed, indicating that the username and password combination was 
incorrectly configured on one of the routers. As it turns out, Cheech had the following command in its 
configuration: 


username Chong password cisco 


Meanwhile, Chong had the following: 


username Chong password Cisco 


As you can see, the passwords must match exactly, and they are case-sensitive. 
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Useful Tips and Tricks 


This section contains additional notes on some useful methods to properly configure your 
ISDN network. Although these notes do not apply to all ISDN networks, they address many 
common configuration mistakes. 


e If you want to have only one router to initiate ISDN calls, omit any dialer maps or dial 
strings on the router that you want to be designated as the called router. The called 
router will obtain the next-hop and dialer information dynamically. 

e For the called router, increase the dialer idle-timeout to a high value. We normally set 
the dialer idle-timeout value to something such as 9999 so that only the calling router 
can terminate the call. For example, if you want an ISDN connection to remain up for 
a minimum of 5 minutes after the call is placed, you must set the dialer idle-timeout 
value to 300 seconds on the calling router. However, if you do not also adjust the 
called router's idle timer value, you will see each call terminate after 120 seconds (the 
default), assuming that no interesting traffic has passed after the connection is made. 
The called router terminating the connection causes this; so to avoid this, you might 
want to set the idle timeout value on the called router to an artificially high number. 

e Don't forget the broadcast keyword on your dialer map statements. If you are 
having difficulties getting routes to traverse the ISDN link, odds are good that the 
broadcast keyword is missing in your dialer map statement. 

e If your link appears to stay up indefinitely, or if you see the link constantly connecting 
right after disconnecting, make your dialer-group list more restrictive. Also, be sure 
that the ISDN interfaces are listed as passive under your routing processes, 

e Be sure to avoid routing loops that might cause the router to consistently dial out. 
This is especially true when using the OSPF demand circuit feature. This can be 
accomplished through distribute lists or route maps under the routing processes. 

e Keep an open mind. Often, there are multiple ways to accomplish the same goal, and 
there are a number of ways that any ISDN network can be configured. 

e For PPP authentication, be sure that the usernames are configured correctly 
(remember, they are case-sensitive), and be sure that the passwords match on each 
router. 

e For OSPF demand circuit configuration, be sure to increase the OSPF cost value of the 
ISDN link so that the preferred path is always over the primary link. Also be sure that 
there are no routing loops in your network, to avoid calls that are made unnecessarily. 

e Configure the optional parameters, such as authentication and caller 1D last. Make 
sure that the ISDN link is working properly first before configuring these advanced 
options. After each of the steps for configuring ISDN have been completed, use the 
appropriate show and debug commands to verify that it is working. You should 
configure the routers incrementally and avoid blindly configuring all the aspects and 
then trying to figure out where you went wrong. 


With practice, you will find the method that works best for you, and this will become your 
default method; however, be prepared to use various methods and understand the "knobs" 
so that you can address various situations. 
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ISDN Labs 


We will now put everything that you have learned into a series of labs similar to those of the 
infamous CCIE Routing and Switching Lab Exam. Here, a set of requirements will be given, 
and it will be up to you to determine how to configure the routers based on those 
requirements. Solutions to these labs also are provided. You might want to continue to read 
the rest of this book before attempting these labs, to gain a better understanding of the 
routing and routed protocols that will be required in these lab configurations. 
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Lab 16: Configuring PPP Authentication, Callback, and Multilink 
over ISDN 


The ABC network consists of the network topology in Figure 7-11. The primary 
communications link is the Frame Relay circuit, with the ISDN line used only as specified in 
the requirements. The CEO of this network is set in his ways. He has asked you to design a 
network for him that meets some specific requirements: 


Figure 7-11. Network Topology for This Lab 


OSPF Area 1 


OSPF Area 0 


J Ethernet _ 


Frame Relay 


1. Configure the network using OSPF as the routing protocol, as shown in Figure 7-11. 


2. Maintain site-to-site connectivity even after a Frame Relay outage. The ISDN link 
should be utilized only when there is a physical break in the frame network or when 
the primary frame link exceeds 50 percent utilization. The ISDN call should wait 10 
seconds after the Frame Relay link goes down in case of a brief outage. The call also 
should get disconnected after 2 minutes upon restoration of the Frame Relay link, or 
after the load on this link goes back down to 25 percent. Only one PVC is expected to 
be used on the Frame Relay interfaces. 


541 


3. Both ISDN B channels are to be utilized immediately whenever a connection is made. 


4. Use authentication, but ensure that the passwords are not encrypted over the ISDN 
link. 


5. Both routers must be capable of initiating ISDN calls. 
6. No static routes are to be used. 


Figure 7-11 shows the network topology for this lab. 


Lab 16 Solution 


Example 7-61 shows the complete solution to this lab, followed by a discussion pertaining to 
it. 


Example 7-60 Configurations for Phoenix2, Phoenix, Green Bay, San 
Diego, and Minneapolis Routers 


Phoenix2#show running-config 
Building configuration: «.. 


Current configuration: 

! 
version 11.2 
no service password-encryption 
no service udp-small-servers 
no service tcp-small-servers 

| 
hostname Phoenix2 

! 
enable password cisco 

! 

! 

interface Ethernet0O 

ip address 170.10.35..2 255.255.2550 
! 

interface Ethernetl 

no ip address 


shutdown 
! 


interface Serial0O 
no ip address 
shutdown 

no fair-queue 

! 

interface Seriall 
no ip address 
shutdown 

! 
router ospf 1 
network 170.10.0.0 0.0.255.255 area 1 
! 
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no ip classless 

! 

! 

line con 0 
exec-timeout 0 0 
privilege level 15 
logging synchronous 
line aux 0 

line vty 0 4 
password cisco 
login 

! 


end 


Phoenix#show running-config 
Building configuration. «. 


Current configuration: 
! 
version 12.0 
service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
! 
hostname Phoenix 
! 
logging buffered 9096 debugging 
! 
ip subnet-zero 
isdn switch-type basic-—dms100 
! 
! 
! 
interface Ethernet0O 
ip address 170..10.35...1. 255.255.2550 


no ip directed-broadcast 
! 


interface Serial0O 
no ip address 
no ip directed-broadcast 
shutdown 
! 
interface Seriall 
description POINT TO POINT LINK TO GREEN BAY 
bandwidth 64 
ip address: 170.:10.238.2 255.259.255.252 
no ip directed-broadcast 
clockrate 125000 
! 
router ospf 1 
network 170.10.0.0 0.0.255.255 area 1 
I 
no ip classless 
I 
! 
! 


line con 0 
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privilege level 15 
logging synchronous 
transport input none 
line aux 0 

line vty 0 4 

login 

! 


end 


Green_Bay#show running-config 
Building configuration. « . 


Current configuration: 

! 

version 12.0 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
! 

hostname Green_Bay 

| 

! 

username San_Diego password 0 isdnlab 
ip subnet-zero 

isdn switch-type basic-—dms100 


interface Ethernet0O 

ip address 170.10.22.1 255.255.255..0 
no ip directed-broadcast 

no keepalive 


interface Serial0 

backup delay 10 120 

backup interface BRIO 

backup load 50 25 

no ip address 

no ip directed-broadcast 

encapsulation frame-relay 

logging event subif-link-status 
logging event dlci-status-change 

no fair-queue 

clockrate 125000 

! 

interface Serial0O.1 point-to-point 

ip address: 170.;10.29.1 255.255.255.252 
no ip directed-broadcast 

frame-relay interface-dlci 300 

l 
interface Seriall 

description POINT TO POINT LINK TO PHOENIX 
bandwidth 64 

ip address: 170.10.23.1 255.259.255.252 
no ip directed-broadcast 

! 


interface BRIO 
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ip address: 170:.10.129..1 255.255.255.252 

no ip directed-broadcast 

encapsulation ppp 

dialer map ip 170.10.129.2 name San_Diego broadcast 6129319360 
dialer load-threshold 1 either 

dialer-group 1 

isdn switch-type basic-—dms100 

isdn spidl 61293199371111 

isdn spid2 61293199381111 

ppp authentication pap 

ppp pap sent-—username Green_Bay password 7 141E010F02082B29 
ppp multilink 

l 

router ospf 1 
network 170.10.22.1 0.0.0.0 
network 170.10.23.1 0.0.0.0 area 1 
network 170.10.29.1 0.0.0.0 area 0 
network 170.10.129.1 0.0.0.0 area 0 
! 
no ip classless 

! 
dialer-list 1 protocol ip permit 

! 

! 

line con 0 

privilege level 15 

logging synchronous 

transport input none 

line aux 0 

line vty 0 4 

login 

I 


end 


San_Diego#show running-config 
Building configuration. «. 


Current configuration: 

! 
version 11.2 
no service password-encryption 
no service udp-small-servers 
no service tcp-small-servers 

! 
hostname San_Diego 

! 

enable password cisco 

! 
username Green_Bay password 0 isdnlab 
ip subnet-zero 
no ip domain-lookup 

isdn switch-type basic-—dms100 
! 

interface Ethernet0O 

no ip address 

no keepalive 

media-type 10BaseT 
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| 
interface Serial0O 
backup delay 10 120 
backup interface BRIO 
backup load 50 25 
no ip address 
encapsulation frame-relay 
! 
interface Serial0O.1 point-to-point 
ip address: 170.10.29..2 255.259.2595; 252 
frame-relay interface-dlci 200 
! 
interface Seriall 
ip address: 170:.10.49.2 (255.255.255.252 
clockrate 125000 
! 
! 
interface BRIO 
ip address 170.10.129.2 255.255.255.252 
encapsulation ppp 
isdn spidl 61293193601111 
as0n, spid2. 6129319776111 
dialer map ip 170.10.129.1 name Green_Bay broadcast 6129319937 
dialer load-threshold 1 either 
dialer-group 1 
no fair-queue 
ppp authentication pap 
ppp pap sent-username San_Diego password 7 09455D0D17091610 
ppp multilink 
| 
interface BRI1 
no ip address 
shutdown 
! 
interface BRI2 
no ip address 
shutdown 
| 
interface BRI3 
no ip address 
shutdown 
| 
router ospf 1 
network 170.10.0.0 0.0.255.255 area 0 
! 


ip classless 
! 


dialer-list 1 protocol ip permit 
! 

line con 0 
exec-timeout 0 0 
privilege level 15 
logging synchronous 
line aux 0 

line vty 0 4 
exec-timeout 0 0 
privilege level 15 
logging synchronous 
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Minneapolis#show running-config 
Building configuration... 


Current configuration: 
! 
version 11.2 
no service password-encryption 
no service udp-small-servers 
no service tcp-small-servers 
! 
hostname Minneapolis 
! 
enable password cisco 
! 
! 
interface Ethernet0O 
ip address: 170310.44.1 255.255.2550 
no keepalive 
! 
interface Serial0 
no ip address 
shutdown 
no fair-—queue 
! 
interface Seriall 
ip address, 170.10.49.1 255.259.255.252 
! 
router ospf 1 
network 1770.10.0.0 0.0.255.255 area 0 
! 
no ip classless 
! 
! 
line con 0 
privilege level 15 
logging synchronous 
line aux 0 
line vty 0 4 
privilege level 15 
password cisco 
no login 
! 


end 
Lab 16 Solution Discussion 


We will keep our discussion here to the Green Bay and San Diego routers because the 
configuration for the other three routers is fairly straightforward. 


Because this lab asked that the ISDN link be utilized after a physical break in the ISDN 
connection, using the backup interface command was the most appropriate solution. In 
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addition, the lab asked you to utilize the ISDN connection if the frame link became 
congested, so the backup load command also was used. Using PPP multilink and setting the 
dialer load-threshold to 1 either way satisfied requirement 3. Using PAP authentication 
completed requirement 4. Finally, both routers used dialer maps in their configurations, 
satisfying requirement 5. This lab did not specifically ask you to use dialer maps, so you 
could have just as easily used dialer strings or dialer profiles. 
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Lab 17: Configuring OSPF Demand Circuits over ISDN 


This lab assumes an in-depth knowledge of the various routing protocols. It might be a good 
idea to read Chapter 12 before attempting this lab. Try to complete this lab on your own by 
doing some research and looking up the necessary commands first before peeking at the 
solution provided. 


Refer to the network diagram in Figure 7-12 for reference; call this network the ABC 
company. 


Figure 7-12. Network Topology for This Lab 


EIGRP 


Phoenix 2 


OSPF Area 0 


JEiereg OSPF Area 1 


Frame Relay 


Green Bay 


Configure the ABC network so that it satisfies the following requirements: 


1. Configure OSPF and EIGRP as shown previously, and be sure to redistribute between 
them to ensure full IP connectivity. 549 


2. The 56-kbps Frame Relay link is the primary means of communication between Green 
Bay and San Diego. You do not want OSPF traffic to be capable of initiating ISDN 
calls, but you do want to maintain total connectivity in the case of a Frame Relay 
outage. ISDN calls should be initiated upon a loss of routes. 


3. Both routers must be capable of initiating calls. Toll charges from Green Bay are 
cheaper, so be sure that the vast majority of ISDN calls is initiated from Green Bay. 


4. You want to authenticate each ISDN connection, ensuring that the passwords are 
hidden using MD5 encryption. 


5. The Green Bay router must be configured so that it will accept incoming calls only 
from the San Diego router. 


6. The ISDN call must disconnect 5 minutes after the routes through the Frame Relay 
link are restored. 


7. The Frame Relay link is only 56 k. Be sure that your configurations reflect this. 
8. No static routes are to be used in this lab. 


Lab 17 Solution 


Example 7-62 shows the final configuration solution that meets the aforementioned 
requirements for this lab. 


Example 7-61 Phoenix 2, Phoenix, Green Bay, San Diego, and 
Minneapolis Router Configurations 


Phoenix2#show running-config 
Building configuration. . 


Current configuration: 

! 

version 11.2 

no service password-encryption 
no service udp-small-servers 
no service tcp-small-servers 
! 

hostname Phoenix2 

! 

enable password cisco 

! 

! 

interface Ethernet0O 


ip address 170.102.3532 2559,2559.255.,0 
! 


interface Ethernetl 
no ip address 


shutdown 
! 
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interface Serial0O 
no ip address 
shutdown 

no fair-queue 

I 

interface Seriall 
no ip address 
shutdown 

! 

router eigrp 1 
network 170.10.0.0 
no auto-summary 

| 

no ip classless 

! 

! 

line con 0 
exec-timeout 0 0 
privilege level 15 
logging synchronous 
line aux 0 

line vty 0 4 
password cisco 
login 

! 


end 


Phoenix#show running-config 
Building configuration... 


Current configuration: 

! 

version 12.0 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
! 


hostname Phoenix 
! 


logging buffered 9096 debugging 

! 

ip subnet-zero 

isdn switch-type basic-—dms100 

! 

! 

! 

interface Ethernet0O 

ip address 170.10.35.1 255.255.2550 
no ip directed-broadcast 

! 

interface Serial0 

no ip address 

no ip directed-broadcast 

shutdown 

I 

interface Seriall 

description POINT TO POINT LINK TO GREEN BAY 
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bandwidth 64 

ip addrésis: 170.10.23.2 255.255.255.252 
no ip directed-broadcast 

clockrate 125000 


router eigrp 1 


network 170.10.0.0 
no auto-summary 


no ip classless 


! 
! 
! 


line con 0 


privilege level 15 
logging synchronous 
transport input none 


line aux 0 
line vty 0 4 


login 


end 


Green_Bay#show running-config 
Building configuration. «. 


Current configuration: 


! 


version 12.0 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 


' 


hostname Green_Bay 


| 
! 


username San_Diego password 0 isdnlab 
ip subnet-zero 
isdn switch-type basic-—dms100 


interface Ethernet0O 


ipvaddress: T70<eL0.22.1. 2552255525520 
no ip directed-broadcast 
no keepalive 


interface SerialO 


! 


no ip address 

no ip directed-broadcast 
encapsulation frame-relay 
logging event subif-link-status 
logging event dlci-status-change 
no fair-queue 

clockrate 125000 


interface Serial0O.1 point-to-point 
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description 56K FRAME RELAY CONNECTION 
bandwidth 56 

ap address: 170.110.2931 255.255.255.252 
no ip directed-broadcast 

frame-relay interface-dlci 300 

! 
interface Seriall 

description POINT TO POINT LINK TO PHOENIX 
bandwidth 64 

ip address: 170.10.23..1 255.255.255;,252 
no ip directed-broadcast 

| 
interface BRIO 

ip address: 170 ,10.129.1 255.255.255.252 
no ip directed-broadcast 

encapsulation ppp 

ip ospt cost 9999 

ip ospf demand-circuit 

dialer callback-secure 

dialer idle-timeout 300 

dialer enable-timeout 5 

dialer map ip 170.10.129.2 name San_Diego class isdnlab broadcast 6129319360 
dialer-group 1 

isdn switch-type basic-—dms100 

agdn spidl, 612931993 714101 

isdn spid2 61293199381111 

isdn caller 6129319360 callback 

ppp callback accept 


ppp authentication chap 
\ 


router eigrp 1 
redistribute ospf 1 metric 64 100 200 10 1500 
passive-interface BRIO 
passive-interface Serial0O.1 
network 170.10.0.0 


no auto-summary 
| 


router ospf 1 
redistribute eigrp 1 metric 100 subnets route-map DENY_BRI_ROUTE 
network 170.10.29.1 0.0.0.0 area 0 
network 170.10.129.1 0.0.0.0 area 0 
passive-interface Seriall 
! 
no ip classless 
! 
! 
map-class dialer isdnlab 
dialer callback-server username 
access-list 1 permit 170.10.129.0 0.0.0.3 
dialer-list 1 protocol ip permit 
route-map DENY_BRI_ROUTE deny 10 
match ip address 1 
| 


route-map DENY_BRI_ROUTE permit 20 
! 


! 
! 
line con 0 
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privilege level 15 
logging synchronous 
transport input none 
line aux 0 

line vty 0 4 

login 

| 


end 


San_Diego#show running-config 
Building configuration. «. 


Current configuration: 
! 


version 11.2 


no service password-encryption 


no service udp-small-servers 
no service tcp-small-servers 
! 

hostname San_Diego 

i} 


enable password cisco 
! 


username Green_Bay password 0 isdnlab 


ip subnet-zero 

no ip domain-lookup 

isdn switch-type basic-—dms100 
! 

interface Ethernet0O 

no ip address 

no keepalive 


media-type 10BaseT 
i} 


interface Ethernetl 
no ip address 
media-type 10BaseT 
! 

interface Ethernet2 
no ip address 
shutdown 
media-type 10BaseT 
! 

interface Ethernet3 
no ip address 
shutdown 
media-type 10BaseT 
! 

interface Ethernet4 
no ip address 
shutdown 
media-type 10BaseT 
| 

interface Ethernet5 
no ip address 
shutdown 


media-type 10BaseT 
| 
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interface Serial0O 

no ip address 

encapsulation frame-relay 

! 
interface Serial0O.1 point-to-point 
description 56K FRAME RELAY CONNECTION 
ip.address: 170.10, 29:2. 25522557295. 252 
bandwidth 56 

frame-relay interface-dlci 200 

! 
interface Seriall 

ip address 170::10.49.2 255.255.255.252 
clockrate 125000 

| 
interface Serial2 

no ip address 

shutdown 

! 
interface Serial3 

no ip address 

shutdown 

! 
interface BRIO 

ip: address. 170.110.1292 255.255.259.252 
encapsulation ppp 

ip ospf cost 9999 

ip ospf demand-circuit 

isdn spidl 61293193601111 

isdn spid2 61293197761111 
dialer idle-timeout 300 

dialer wait-—for-carrier-time 10 

dialer map ip 170.10.129.1 name Green_Bay broadcast 6129319937 
dialer-group 1 

no fair-queue 

ppp callback request 

ppp authentication chap 

! 

interface BRI1 

no ip address 

shutdown 

! 

interface BRI2 

no ip address 

shutdown 

! 

interface BRI3 

no ip address 


shutdown 
! 


router ospf 1 

network 170.10.29.2 0.0.0.0 area 0 
network 170.10.129.2 0.0.0.0 area 0 
network 170.10.49.2 0.0.0.0 area 1 
! 

ip classless 

! 


dialer-list 1 protocol ip permit 
! 
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line con 0 
exec-timeout 0 0 
privilege level 15 
logging synchronous 

line aux 0 

line vty 0 4 
exec-timeout 0 0 
privilege level 15 
logging synchronous 
no. Login 
I 


end 


Minneapolis#show running-config 
Building configuration... 


Current configuration: 
! 
version 11.2 
no service password-encryption 
no service udp-small-servers 
no service tcp-small-servers 
! 
hostname Minneapolis 
! 
enable password cisco 
! 
| 
interface Ethernet0O 
ip address 170.10.44.1 255.255.255.0 


no keepalive 
! 


interface Serial0 

no ip address 
shutdown 

no fair-queue 

! 

interface Seriall 

ip address: 170.10.49.1 255.255.255.252 
I 

router ospf 1 
network 170.10.0.0 0.0.255.255 area 1 
! 
no ip classless 

! 

! 

line con 0 

privilege level 15 
logging synchronous 
line aux 0 

line vty 0 4 
privilege level 15 
password cisco 

no login 

I 


end 
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Lab 17 Solution Discussion 


Again, nothing special is going on with the Phoenix, Phoenix 2, and Minneapolis 
configurations. They are being used here only to generate routes. The bulk of the 
configuration commands needed for this lab are done with the Green Bay router. 


This lab hinted at the use of OSPF demand circuit, in that it asked the ISDN link to be 
brought up in the case of a loss of routes over the Frame Relay connection. If the lab had 
asked you to have the ISDN line come up in case of physical loss of connectivity on the 
Frame Relay link, using the backup interface option would have been more appropriate. 


To satisfy requirement 3, Green Bay was set up as a callback router. Requirement 4 asked for 
authentication using MD5 encryption, so CHAP had to be configured. We also set it up with 
ISDN caller 1D to satisfy requirement 5. Both Green Bay and San Diego have dialer map 
statements, so both have the capability to issue ISDN calls. Requirement 6 was satisfied with 
setting the dialer idle-timeout to 300 seconds on both ends of the ISDN connection. 


The biggest issue with this particular lab is getting the ISDN line to remain quiet when the 
network is stable. If you were able to do this without first looking at the solution, you should 
be proud of your accomplishment. 


The important thing to notice about the Green Bay router configuration is the use of the 
route map statement when redistributing EIGRP into OSPF. Recall from the OSPF demand 
circuit section that sometimes you need to do more than simply issue the ip ospf demand- 
circuit command. This lab network is a classic example of this. When redistributing ElGRP 
into OSPF on the Green Bay router, you have effectively created a routing loop because the 
BRI interface (170.10.129.1) also is included with the EIGRP network. Because of this, this 
interface constantly is being redistributed into OSPF from EIGRP, and vice versa. To fix this, 
you needed to use a route map to deny the 170.10.129.0/30 network from being 
redistributed into OSPF. An alternative to using a route map would have been to use a 
distribute list, denying this network from being redistributed. 


One other important thing to note is the use of the ip ospf cost 9999 command under the 
BRI interface of the Green Bay and San Diego routers. Remember that requirement 7 of the 
lab basically requires you to use the bandwidth 56 command under interface sO.1 of both 
routers. Because of this, OSPF actually preferred the BRI link because it had a lower cost. 
This was fixed by increasing the OSPF cost to an artificially high number on the BRI interface. 
This number didn't have to be this high, but we chose to use 9999 for emphasis. You also 
could have used the ip ospf cost command on the Serial 0.1 of these routers to decrease 
the cost. 
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Summary 


The topic of ISDN is vast and comprehensive, and it is a core topic of the CCIE Routing and 
Switching Lab Exam. If you don't have a firm grasp of the topics described in this chapter, 
you have a slim chance of getting your CCIE number. The best way to prepare for the ISDN 
portion of this rigorous exam is to practice these topics. You cannot possibly retain the 
knowledge contained in this chapter if you do not have the equipment necessary to practice 
these topics repeatedly. We cannot stress this enough. If you don't have access to ISDN 
equipment, you will need to purchase an ISDN simulator and some routers with BRI 
interfaces. Reading about any topic is one thing. The practical knowledge obtained from 
actually doing it is something else entirely. 


Try to add as many complexities to the ISDN topics as you can. Use different routing 
protocols, and note how they change the configurations. Add IPX and other routed protocols 
to the configurations to see how they affect the outcome. After that, try configuring BGP, 
DLSw, and NAT over the ISDN link. It is relatively easy to configure any single topic on a 
Cisco router. However, when multiple things are configured and integrated, unexpected 
issues can arise. The only way to learn about these issues is to practice as many different 
topics as you can and then integrate them 
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Chapter 8. WAN Protocols and Technologies: 
Asynchronous Transfer Mode (ATM) 


Authoring contribution by Galina Diker Pildush 


Asynchronous Transfer Mode (ATM) has been looked upon as the technology that can do it all 
—carry voice, data, and video information, implying that both voice and data payloads, batch 
and real-time, can be transferred from one part of the world to another. This is implemented 
with guarantees in quality, such as integrity of the information and its throughput, toward 
different classes of services. In my book Cisco ATM Solutions, | elaborate on the whys and 
whats with respect to ATM. It is the technology that instilled in me a sense of the simplicity 
and beauty within it. 


The concept behind ATM is quite simple: Push into the ATM cloud equal-size payloads (an 
ATM cell consists of a 48-byte payload and a 5-byte header) that consist of any type of 
applications above it. Perform no error checking of these payloads; do not waste any 
overhead on useless things such as sequence numbers (because ATM is connection- oriented 
anyway), just to perform error checking of the ATM header (which is done at the silicon 
layer); and zoom through those payloads as fast as you can at a low layer of the OSI 
reference model. ATM operates on 1.25 layers of the OSI reference model—exactly, 1.25 
layers! Figure 8-1 provides the information about the ingredients of an ATM cell. 


Figure 8-1. ATM Cell Format 
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Cell Header — 5 bytes 
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Table 8-1 lists the meaning of the cell header fields. 


Table 8-1. ATM Cell Header Fields 


| Field | Size | Meaning 
|GFC 4 bits Generic Flow Control: Used at the UNI level. 


VPI /|8 or 12 Virtual Path Identifier: Part of ATM locally significant 
bits address. It is 8 bits at the UNI and 12 bits at the NNI. 
VCI {16 bits Virtual Channel Identifier: Part of the ATM locally 
significant address. 
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PT Payload Type. The 3 bits are used as follows: The most 
Significant bit is used to identify the data versus the OAM 
cell, the next bit is used to identify congestion on the 
network (it is called Explicit Forward Congestion Indication 
[EFCI]), and the last bit is used to identify the last cell of 
a higher-level packet/frame. This bit, called End of 
Message, is important in the congestion control algorithm 


within the ATM cloud. 


CLP {1 bit Cell Loss Priority: Used to indicate if a cell can be 
discarded by the network, in case there is congestion. 


HEC {8 bits Header Error Check. The ATM cloud does not perform 
payload error checking, only the header error checking. 


The powerful concepts of ATM's Private Network-to-Network Interface (PNNI) helped in the 
development of such protocols as MPLS with traffic engineering, which introduces a 
connection- oriented flavor to connectionless IP. PNNI is a routing protocol deployed by the 
ATM signaling protocol to establish SVCs. 


Recognizing ATM's impact on the customer's enterprise networks, Cisco introduced 
interconnections of various protocols over ATM into its Routing and Switching CCIE 
certification. This chapter discusses two methods of protocol interconnectivity over ATM that 
address implementation from the edge device perspective: 


e RFC 2684, "Multiprotocol Encapsulation over ATM Adaptation Layer 5" 
e RFC 2225, "Classical |P and ARP over ATM" 


The implementations of the actual ATM cloud are not currently in the CCIE practical exam. 
See the Cisco ATM Solutions book for the implementations of the cloud itself. 


The whole objective of ATM internetworking is to send upper-layer information over ATM. 
Four implementation methods exist for achieving that goal: 


e Manual method for multiple upper-layer protocols by using RFC 2684. | call ita 
method without any magic "upstairs" in the upper layers of the OSI reference model. 

e Dynamic method for IP implementation by using RFC 2225 (Classical IP). | call ita 
method with the magic of transporting IP over ATM. 

e Dynamic method for Layer 2 protocols by using Local-Area Network Emulation (LANE). 

e Dynamic method for all Layer 2 and Layer 3 protocols by using Multiprotocol over ATM 
(MPOA). 


This chapter focuses on the first two methods—RFC 2684 and RFC 2225. 


The two labs presented in the chapter provide you with additional practical exercises. If you 
require information on other interconnection methods (for example LANE, MPOA, and so on) 
or more examples/labs, refer to the Cisco ATM Solutions book. 
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Special Components Needed for ATM Lab Studies 


| recommend the following equipment for your ATM exercises: 


e One LightSteam 1010 (LS1010) ATM switch 
e Two or three routers with ATM interfaces 


If you have problems accessing LS1010, you can attend Cisco's "Campus ATM Solutions" class 
before going to a lab. The class has several LS1010s with routers, providing you with the 
necessary gear. Also, the Cisco ATM Solutions book provides many configuration examples/labs to 
enhance your comfort level with ATM. 


This chapter focuses on the routers' configurations. Typically, the LS1010 does not require any 
special configuration unless you have a network of LS1010s. Cisco ATM Solutions provides 
elaborate examples and explanations on LS1010 configuration, if you ever have a need to 
configure one. 


The routers can include a 4XXX, 7XXX, or 36XX series model. Cisco has a rich assortment of 
product lines that include routers and switches with ATM interfaces. Table 8-2 illustrates this 


variety. It is important to note the assortment of ATM adaptation layers (AALs), User-Network 
Interface (UNI) types, and ATM service categories that are supported. 


Table 8-2. Cisco ATM Edge Devices Summary Table! 


Supported Supported 
Edge Supported ATM ATM 
Device |Switch | Traffic Interface |Supported |Supported | Service 
Model | Type Type Speeds AAL UNI Categories 
26XX Layer 3 |Voice and = _|1x25 Mbps UBR, ABR, 
data CBR, nrt- 
4xDS-1/E1 VBR, rt- 
with (IMA) VBR 


8xDS-1/E1 
with IMA 


DS-3/E3 
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36XX Layer 3 |Voice and 
3810 Layer 3 |Voice and 
data 
em Layer 3 |Data 1xOC- 3/ AAL5, 
re Layer 3 


6400 
. Layer 3 


72XX Layer 3 |Voice and 
data 


Voice and 
data 


Layer 3 


8xDS-1/E1 |AALS5, 
with IMA AAL1 
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8xDS-1/El1 (AALS, 
with IMA AAL1 


LxDS-3/E3 


1xOC-3/ STM- 
1 


7400 Layer 3 |Data 
75XX Layer 3 |Data 
ee Layer 3 |Data 
12000 _ J|Layer 3 |Data 


Catalyst |Layer 2 |Data 1xOC- 3/ 
2820 STM-1 


Catalyst |Layer 2 |Data 
2900 
Catalyst |Layer 2 |Data 
3900 


Voice and 
data 


1xOC-3/ STM- 
1 


1xOC-12/ 
STM-4 


1xDS-3/E3 


8xDS-1/E1 
with IMA 


1xOC-12/ 
STM-4 


4xOC-3/ STM- 
1 


1xOC- 3/ 
STM-1 


25 Mbps 
DS-1/E1 
DS-3/E3 


1xOC-3/ STM- 
1 


1xOC-12/ 
STM4 


564 


Catalyst |Layer 2 |Data 
6000 


Catalyst |Layer |Voice and 


85XX 


Table 8-2 is taken from Cisco ATM Solutions, Galina Diker Pildush, Cisco Press. 


[1] Table 8-2 information is based on Cisco's product catalog as of August 2001. 


[2] A member of the Catalyst 8500 family, the Catalyst 8540MSR, can also be an 
ATM switch. It can accept not only new modules, but also existing LightStream 
1010 modules. 


Cisco has various ATM router interfaces supported on multiple platforms, as illustrated in Table 8- 
a. 


Table 8-3. NPM, AIP, ATM PA-A1, and ATM PA-A3 Comparison 


Physical 
I nterfaces/ 


Features AIP ATM PA-Al | ATM PA-A3 
Platform 4500, 4700 = 7500 7200, VIP2- |7200, VIP2- 
based 7500 |based 7500 
OC-3 MMF Support /Yes Yes Yes a 


|Oc- 3 SMF Support Yes Yes Yes 
iDS- 3/ E3 Support ie is Ne re 


TAXI Support 


UNI Supported 2B Te 1/4.0 20nr 7 1 = Soe Ar UERIZRI 


[LANE Support = [LANE Support = Yes 


RFC 2684, 2225 Yes 
Support 
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PVCs (as per 11.1 
(22)C) 


PVCs, SVCs 


PVCs, SVCs |PVCs, SVCs 


Types of VCs 
Supported 


Maximum pps (64 |— 110,000 pps 
byte, bidirectional) 
Simultaneous 256 (can be 


SARs (# of Up te: S12) 
packets) 


SVCs (IOS 12.0) 


150,000 pps |170,000 pps 


og 1024 


Maximum number 2048 2048 
of VCs 
AAL Support AAL3/4, AAL5 |AAL5 


UBR UBR nrt-VBR, UBR, 


ABR 


ATM Service 
Category Support 
Traffic Shaping Yes Yes None 
Support 


OAM Support! F4, F5 (as of |F4, F5 (as of |F4, F5 (special 
11.32) T Li 32) T. release 11.1(22) 
Cisco |OS Cisco |OS CC and 12.0) 
Software) Software 
and 11.1(22) 
CC) 


Table 8-3 is taken from Cisco ATM Solutions, Galina Diker Pildush, Cisco Press. 
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Configuring RFC 2684 


The complete theory behind RFC 2684 is covered in Cisco ATM Solutions. Here, | want to 
remind you that RFC 2684 (formerly RFC 1483) is an encapsulation method of all routed or 
bridged protocols over ATM. My formula for RFC 2684 is as follows: 


RFC 2684 is the multiprotocol encapsulation method. The encapsulation 
method of multiple protocols (Layer 3 or bridged) over a single VC is 
accomplished using LLC/SNAP; the encapsulation method of a single protocol 
over a single VC is done using mux. Both PVCs and SVCs are supported, 
provided that the ATM cloud can support PVCs or SVCs. 


A permanent virtual circuit (PVC) is a statically defined route, whereas a switched virtual 
circuit (SVC) is a dynamically defined route through signaling. In this section, you learn the 
principles behind the implementation of both PVCs and SVCs. 


RFC 2684 is a basic encapsulation method, without any "magic" behind it. Your protocol 
addresses must be manually mapped to the ATM addresses by using either the VPI/VCI pair 
in the PVC implementation or the NSAP/E.164 address in the SVC implementation. 


Let's examine the details of PVC and SVC methods of implementations. 
PVC Implementation 


The PVC implementation is a static and tedious process from within the ATM network itself. If 
you implement the PVC-based ATM networks, please be careful to make sure that the 
information on the VPI/VCI numbers is precise. One mistake on a VPI/VCI number(s) can 
lead to devastating unpredictable results, like ending up in Moscow instead of NewYork for 
your connection. Recall that VPI/VCI numbers are locally significant addresses used in ATM's 
PVC implementations. 


For the purpose of this chapter discussion, assume that the ATM network has been configured 
correctly. 


You can implement PVC networks by using one of two methods: 


e Static VPI/VCI assignment, where you have to enter VPI/VCI numbers manually based 
on the providers information 

e Dynamic VPI/VCI assignment, where your edge routers obtain VPI/VCI numbers 
dynamically from the edge ATM switch 


In either method, VPI/VCI numbers are locally significant. 
NOTE 


VPI/VCI numbers are similar to DLCIs in Frame Relay networks, where the DLCl 
is locally significant. The local significance applies all the way to the interface 
level. That is, if various router ATM physical interfaces have identical VPI/VCI 
numbers, they are treated as independent connections to the ATM network. 
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The static configuration involves full manual intervention. If VPI/VCI assignments change 
within the ATM cloud, you need to adjust the configurations within the routers manually. The 
dynamic discovery of VPI/VCl numbers is much more appealing because the attached routers 
learn the information from their respective adjacent switches dynamically. The discovered 
PVCs and their traffic parameters are configured on the ATM main interface or subinterface 
that you specify. Your router receives the PVC parameter information by using Interim Local 
Management Interface (ILMI). 


Let's examine the syntax and configuration examples for both methods of PVC-based network 
implementation. Figure 8-2 illustrates our implementation example. 


Figure 8-2. PVC-Based Configuration Example 


IP on 131.108.172.0 
IFX=172.0000,0000,.0002 
ASAP ed? OOM 2oM 2M sh seos. 2 


RouterB (>= 8 


= 131.108.16¢ 


IP = 190,008,171 0 
IPR = 177.0000,.0000.0001 
ASAP 247 00070000 O01 1 101. 111071100110.00 


IP=131,108.170.0 
IP e 170.0000.0000.00005 
NSAP a4 7 OS OMIOO0I D000 P03.399033909330.00 


The three routers (A, B, and C) connected to the ATM cloud handle two protocols—IP and 
IPX. From the OSI model Level 3 perspective (network layer), all the routers are 
interconnected through one single IP and IPX networks—131.108.168.0/24 and network 100. 
Each of the routers has another IP and IPX network attached. 


Static PVC Implementation 


Example 8-1 presents the configurations for Routers A, B, and C. Notice that the 
subinterfaces are used to interconnect routers over the ATM cloud. You can use major 
interfaces instead. Use of the subinterfaces, however, positions you with a more scalable 
configuration. 
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Also, the example illustrates the use of LLC/SNAP encapsulation (as opposed to mux). LLC/ 
SNAP encapsulation positions your VCs to carry multiple protocols, whereas mux 
encapsulation carries only one protocol. 


NOTE 


| can think of only one instance when you would need a single protocol to be 
carried over a single VC: when you require to do traffic shaping of individual 
protocols. Assume that you have IP and IPX to carry over ATM network. If you 
need to define different traffic-shaping parameters to IP and IPX, you would 
deploy mux encapsulation. 


Example 8-1 FC 2684 Static PVC Configuration for Multiprotocol 
Encapsulation 


Router A (config)# interface atm 0.1 multipoint 
ip address 131.108.168.1 255.255.255.0 

ipx network 100 

atm pvc 10 0 100 aal5snap 

atm pvc 11 0 200 aal5snap 

map-group pvc-static-—routerA-ip 

map-group pvc-static—routerA-ipx 


map-list pvc-static-—routerA-ip 

ip 131.108.168.2 atm-vc 10 broadcast 

ip 131.108.168.3 atm-vc 11 broadcast 
map-list pvc-static—routerA-ipx 

ipx 100.0000.0000.0002 atm-vc 10 broadcast 
ipx 100.0000.0000.0003 atm-vc 11 broadcast 


Router B (config)# interface atm 0.1 multipoint 
ip address 131.108.168.2 255.255.255.0 

ipx network 100 

atm pvc 10 0 200 aal5snap 

atm pvc 11 0 210 aal5snap 

map-group pvc-static—routerB-ip 

map-group pvc-static—routerB-ipx 


map-list pvc-static—routerB-ip 

ip 131.108.168.1 atm-vc 10 broadcast 

ip 131.108.168.3 atm-vc 11 broadcast 
map-list pvc-static—routerB-ipx 

ipx 100.0000.0000.0001 atm-vc 10 broadcast 
ipx 100.0000.0000.0003 atm-vc 11 broadcast 


Router C (config)# interface atm 0.1 multipoint 
ipx network 100 

ip address 131.108.168.3 255.255.255.0 

atm pvc 10 0 300 aal5snap 

atm pve 11 0 310 aal5snap 

map-group pvc-static—routerC-ip 


map-list pvc-static—routerC-—ip 
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ip 131.108.168.1 atm-vc 10 broadcast 

ip 131.108.168.2 atm-vce 11 broadcast 
map-list pvc-static—routerC—ipx 

ipx 100.0000.0000.0001 atm-vc 10 broadcast 
ipx 100.0000.0000.0002 atm-vc 11 broadcast 


The configurations are quite simple, with no magic involved: You need to manually assign the 
PVCs with an encapsulation method—in this case, by using aal5snap encapsulation—and then 
you need to manually map the corresponding next-hop IP and IPX addresses to the 
corresponding PVC's VPI/VCI that takes you to the destination address of the corresponding 
protocol. VPI/VCl numbers must be obtained from an entity managing the ATM cloud. Cisco 
10S mapping is done using map-lists that are defined in the global configuration mode and 
then referenced using map-groups. Please note that the example illustrates the use of two 
map-lists, each one dedicated for a specific protocol (in this case, 1P and IPX). Although you 
can have one map-list referring to both protocols, | strongly recommend deploying a 
separate a map-list per protocol, for modularity reasons. 


Figure 8-3 illustrates the complete syntax of the command, with explanations provided in 
Table 8-4. For more in-depth information and further examples of the static PVC 
implementations by using RFC 2684 encapsulation, refer to Cisco ATM Solutions. 


Figure 8-3. Static PVC Command Syntax 


IP, IPX, etc.) 
es 


LLGVSNAP 
PCY per protocol 
Signaling PWC 

HSSIFA 


Router (contig-if) # 


—, 


CATM vital path) peak rate fees size 
(rate queue) ala 
ATM virtual cic) ( Set average rate 


Starting/Ending 
message identifier 
Number of AALS 
PC 


Set Inverse ARP 
(minutes) 


Table 8-4. Descriptions of atm pvc Command Arguments 
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| Field | Description 


vcd Virtual circuit descriptor. It uniquely identifies the PVC in the 
router. It must be unique in the entire router because there is a 


reference to that number from the global configuration level. The 
vcd numbers stay in the routers. 


vpl Virtual path identifier. This is a part of the ATM VC address. It 
must match the carrier-provided VPI for a specific destination and 
ie 


must be unique within a physical interface of the router. 


Virtual channel identifier. This is a part of the ATM VC address. It 
must match the carrier-provided VCI for a specific destination and 


must be unique within a physical interface of the router, 


This is a mandatory parameter that identifies the ATM adaptation 
layer (AAL) and encapsulation type. Figure 8-2 identifies the 
various encapsulation types. 


This is optional parameter. It is set for the aal34smds 
encapsulation only. It is the starting message identifier (MID) 
number for this PVC. The default is 0. If you set the peak and 
average (burst is optional) values for aal34smds encapsulation, 
you also must set the midlow and midhigh values. This option is 
not available for the ATM port adapter. 


This is optional parameter. It is set for the aal34smds 
encapsulation only. It is the ending MID number for this PVC. The 
default is 0. If you set the peak and average (burst is optional) 
values for aal34smds encapsulation, you also must set the midlow 
and midhigh values. 


This is an optional parameter that signifies the maximum rate at 
which this virtual circuit can transmit, in kilobits per second. By 
default, peak = 155,000 kbps. /41 

This is an optional parameter that signifies the average rate at 
which this virtual circuit transmits, in kilobits per second. By 
default, average = 155,000 kbps. /41 


This is an optional parameter. It is the value that relates to the 
maximum number of ATM cells that the VC can transmit to the 
network at the peak rate of the PVC. The default value varies, 

based on the model of the router. For example, the 7XXX series 


default burst value = g4l2l [3] 


This is an optional parameter to enable Inverse ARP on the PVC 
(works only for IP, which is RFC 2225, "Classical |P"). The Inverse 
ARP datagrams are sent every x minutes on this PVC. The default 
value is 15 minutes. 


burst 


inarp x 
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This is an optional parameter that configures the transmission of 
OAM F5 loopback cells every x seconds. The OAM F5 cells verify 
connectivity on the virtual circuit. The remote end must respond 


by echoing back such cells. 


Information excerpted from Cisco ATM Solutions, Galina Diker Pildush, Cisco 
Press. 


[1] The reference to the physical interface should not be confused with the 
subinterface notation. Cisco routers treat the subinterfaces as real physical 
interfaces, each of which is a separate broadcast domain that can have unique 
traffic control and policy being definitions, using access lists, for example. The 
VPI/VCI must be unique within an actual physical interface range, simply 
because an ingress ATM switch has no idea how to "spell" the word 
subinterface. 


[2] The peak, average, and the burst numbers are the PCR, SCR, and BT 
values that are used by the router to perform traffic shaping using the leaky 
bucket algorithm, which is discussed in Chapter 4, "ATM Traffic and Network 
Management," of the Cisco ATM Solutions book. 


[3] The default burst value of 94 for the 7XXX series signifies that the default 
burst tolerance is 94 tokens. Each token in the 7XXX series handles 32 cells. 
In the 4XXX series, each token handles only one cell. Therefore, in the Cisco 
literature, you sometimes see a reference to "cells" in the 4XXX commands 
and to "tokens" in the 7XXX commands. 


Dynamic PVC Implementation 


The dynamic PVC setup is not as manually intensive as the static method. Still, you use PVCs, 
which are set up permanently through the ATM cloud. The dynamics here involve automatic 
discovery of the VPI/VCI numbers by using the Integrated Local Management Interface 
(ILMI). To use ILMI, you need to define the ILMI PVC, by using VCI = 16, per ATM Forum 
specifications. When you enter the command atm ilmi-pvc-discovery subinterface, the 
ILMI PVC carries the PVC identifier. Example 8-2 presents more detail on dynamic PVC 


implementation. 


Example 8-2, based on Figure 8-2, illustrates dynamic PVC implementation. 


Example 8-2 Dynamic PVC Configuration for Multiprotocol 
Encapsulation 


Router A (config)# interface atm 0 
atm pvc 1 0 16 ilmi 

atm ilmi-pvc-discovery subinterface 
interface atm 0.1 multipoint 

ip address 131.108.168.1 255.255.255.0 
ipx network 100 


Router B (config)# interface atm 0 
atm pvc 1 0 16 ilmi 
atm ilmi-pvc-discovery subinterface 
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interface atm 0.1 multipoint 
ip address 131.108.168.2 255.255.255.0 
ipx network 100 


Router C (config)# interface atm 0 
atm pvc 1 0 16 ilmi 

atm ilmi-pvc-discovery subinterface 
interface atm 0.1 multipoint 

ip address 131.108.168.3 255.255.255.0 
ipx network 100 


Please note the specification of the subinterface keyword in the atm ilmi-pvc-discovery 
command. This enables the discovered PVCs to reside on an ATM subinterface that is 
specified below. The discovered PVCs are assigned to the subinterface number that matches 
the VPI number of the discovered PVC. In the example, the discovered PVCs must have a VPI 
value of 1 to be assigned to the subinterface 0.1. 


Notice that static mapping is not defined. When PVC discovery is enabled on an active PVC 
and the router terminates that PVC, the PVC generates an ATM Inverse ARP request. This 
allows the PVC to resolve its own network addresses without configuring a static map. 


Address mappings learned through Inverse ARP are aged out. However, mappings are 
refreshed periodically. This period is configurable using the inarp command, which has a 
default of 15 minutes. It is interesting to note that Inverse ARP initially was available only for 
IP, following RFC 2225 (Classical IP). Currently, Cisco 1|OS Software extends the availability of 
Inverse ARP to the IPX protocol as well. The "Configuring RFC 2225 (Classical IP)" section of 


the chapter elaborates more on this subject. 


NOTE 


The fact that dynamically discovered PVCs use ATM Inverse ARP requests is 
somewhat similar to the Classical |P behavior. Although Classical |1P architecture 
truly does focus on IP protocol only, Cisco extended this capability to the I PX 
protocol as well. 


SVC Implementation 


The SVC implementation is much more dynamic and resilient than the PVC implementation. 
Why? Simply because SVCs are set up on demand, without manual intervention. If traffic 
needs to get from point A to point Z, signaling sets up the VC dynamically, using either a 
static or a dynamic ATM routing protocol, through the ATM cloud. After the VC is set up, the 
traffic can flow through, utilizing the preset path. After the VC is set, all the traffic from 
source to destination takes the same path. The beauty of an SVC is that you do not have to 
worry about ATM network availability (provided, of course, that the entire ATM cloud is alive). 
If a problem exists with one of the links that is used for a preset VC, a new VC is set up for 
your traffic dynamically, using Q.2931 signaling. Several methods exist for SVC setup, using 
static routes or dynamic routing protocols; that discussion is outside the scope of this book, 
however, and can be found in Cisco ATM Solutions. 


Because SVCs are set up dynamically, the addressing scheme is different from that of PVCs. 
The PVC's address, which is a VPI/VCI combination, is locally significant. The local 
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significance makes total sense—no protocol at the ingress of the ATM network carries the 
ATM address of the destination dynamically through the cloud. The SVC address, on the other 
hand, is globally significant, which also makes total sense. The ATM edge device that needs 
to pass on the information received through the ATM cloud is responsible for setting up the 
VC. It does this by using the signaling protocol, Q.2931, which carries the information about 
the ATM destination and QoS parameters. Path selection within the ATM cloud and number of 
hops (ATM switches) for this VC setup is immaterial for the IP layer. 


The SVC ATM address format consists of 160 bits or 40 hexadecimal numbers, as illustrated 
in Figure 8-4. If you use a private ATM network, you would use an NSAP-based ATM address. 


If you use a public ATM network, you would use an E.164-based ATM address. Cisco ATM 
Solutions discusses the various ATM address formats in depth. 


Figure 8-4. SVC ATM Address Format 


20 bytes (40 Hex Digits) 
| Prefix ESI 1 | 
~~ 13 bytes (26 hex digits) 5 bytes (12 hex digits) —>|+byte 
47.0091.8100.0000 Switch Prefix 


Although the address seems quite long and tedious to input (it is expressed in hexadecimal 
notation), do not fear. The ATM Forum foresaw that this would be a problem and allowed the 
addresses to be learned dynamically using ILMI. All you have to assign is the end station 
identifier (ESI), consisting of 12 hexadecimal numbers and 2 hexadecimal selector numbers. 
The prefix is obtained automatically from the immediately attached ATM switch by using 
ILMI. Various options are available for the ESI assignment—you can use the MAC address of 
one of the LAN interfaces of a router, or you can assign an arbitrary address coinciding with 
the interface's IP address. For example, if the IP address of the ATM interfaces (or 
subinterface) is 177.10.168.1, you can assign the ESI to be 0177.1016.8100. 


Use of ILMI requires you to set up an ILMI PVC by using VCI=16, as identified by the ATM 
Forum. 


Table 8-5 addresses the similarities and differences of SVC implementation and PVC 
implementation. 


Table 8-5. SVC Versus PVC I mplementation 


| Similarities | Differences 


Assigning an ATM address to an Different form of the ATM 
interface or subinterface addresses: global addresses 
Statically mapping Layer 3 next-hop a_ |Need to create PVCs for signaling 
ddresses to the corresponding ATM and, optionally, |LMI 


addresses (using global ATM 
addresses) 


RFC 2684 implementation includes either manual assignment of full ATM address to the ATM 
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edge devices or manual assignment of only the ESI portion of the NSAP address and 
deployment of the ILMI. Example 8-3, based on Figure 8-1, illustrates the RFC 2684 SVC 
implementation for the edge device routers A, B, and C. The configurations presented include 
RFC 2684 handling of IP and IPX protocols. Full NSAP addresses are assigned to routers A, B, 
and C. 


Example 8-3 RFC 2684 SVC Configuration for Multiprotocol 
Encapsulation 


Router A (config)# interface atm 0 
atm pvc 5 0 5 qsaal 


interface atm 0.1 

ip address 138.108.168.1 255.255.255.0 

atm nsap-address 47.000100010001000100010001 .111011101110.00 
map-group ip-routerA 

map-group ipx-routerA 


map-list ip-routerA 
ip 131.108.168.2 atm-nsap 47.000200020002000200020002 .222022202220.00 broadcast 
ip 131.108.168.3 atm-nsap 47.000300030003000300030003 .333033303330.00 broadcast 


map-list ipx-routerA 

ipx 100.0000.0000.0002 atm-nsap 47.000200020002000200020002 .222022202220.00 
broadcast 

ipx 100.0000.0000.0003 atm-nsap 47.000300030003000300030003 .333033303330.00 
broadcast 


Router B (config)# interface atm 0 
atm pvc 5 0 5 qsaal 


interface atm 0.1 

ip address 138.108.168.2 255.255.255.0 

atm nsap-address 47.000200020002000200020002 .222022202220.00 
map-group ip-routerB 

map-group ipx-routerB 


map-list ip-routerB 
ip 131.108.168.1 atm-nsap 47.000100010001000100010001.111011101110.00 broadcast 
ip 131.108.168.3 atm-nsap 47.000300030003000300030003 .333033303330.00 broadcast 


map-list ipx—-routerB 

ipx 100.0000.0000.0001 atm-nsap 47.000100010001000100010001.111011101110.00 
broadcast 

ipx 100.0000.0000.0003 atm-nsap 47.000300030003000300030003 .333033303330.00 
broadcast 


Router C (config)# interface atm 0 
atm pvc 5 0 5 qsaal 


interface atm 0.1 

ip address 138.108.168.3 255.255.255.0 

atm nsap-address 47.000300030003000300030003 .333033303330.00 
map-group ip-routerC 

map-group ipx-routerC 


map-list ip-routerC 
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ip 131.108.168.1 atm-nsap 47.000100010001000100010001 .111011101110.00 broadcast 
ip 131.108.168.2 atm-nsap 47.000200020002000200020002 .222022202220.00 broadcast 


map-list ipx—-routerC 

ipx 100.0000.0000.0001 atm-nsap 47.000100010001000100010001.111011101110.00 
broadcast 

ipx 100.0000.0000.0002 atm-nsap 47.000200020002000200020002 .222022202220.00 
broadcast 


Example 8-4, based on Figure 8-1, illustrates another RFC 2684 SVC implementation for the 
same edge devices. This example illustrates the ESI portion of the ATM address assigned to 
the routers’ interfaces. ILMI is used to obtain the NSAP prefix portion from the immediately 
attached ATM switch. Notice that Example 8-3 had only signaling PVCs, whereas Example 8-4 
illustrates the use of two PVCs—signaling and ILMI. The signaling and |LMI PVCs must be 
assigned to the major interface. 


Example 8-4 RFC 2684 SVC Configuration for Multiprotocol 
Encapsulation 


Router A (config)# interface atm 0 
atm pvc 5 0 5 qsaal 
atm pvc 2 0 16 ilmi 


interface atm 0.1 

ip address 138.108.168.1 255.255.255.0 
atm esi-address 111011101110.00 
Map-group ip-routerA 

map-group ipx-routerA 


map-list ip-routerA 
ip 131.108.168.2 atm-nsap 47.000200020002000200020002 .222022202220.00 broadcast 
ip 131.108.168.3 atm-nsap 47.000300030003000300030003 .333033303330.00 broadcast 


map-list ipx-routerA 

ipx 100.0000.0000.0002 atm-nsap 47.000200020002000200020002 .222022202220.00 
broadcast 

ipx 100.0000.0000.0003 atm-nsap 47.000300030003000300030003 .333033303330.00 
broadcast 


Router B (config)# interface atm 0 
atm pvc 5 0 5 qsaal 
atm pvc 2 0 16 ilmi 


interface atm 0.1 

ip address 138.108.168.2 255.255.255.0 
atm esi-address 222022202220.00 
map-group ip-routerB 

map-group ipx-routerB 


map-list ip-routerB 
ip 131.108.168.1 atm-nsap 47.000100010001000100010001.111011101110.00 broadcast 
ip 131.108.168.3 atm-nsap 47.000300030003000300030003 .333033303330.00 broadcast 


map-list ipx—-routerB 
ipx 100.0000.0000.0001 atm-nsap 47.000100010001000100010001.111011101110.00 
broadcast 
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ipx 100.0000.0000.0003 atm-nsap 47.000300030003000300030003 .333033303330.00 
broadcast 


Router C (config)# interface atm 0 
atm pvc 5 0 5 qsaal 
atm pvc 2 0 16 ilmi 


interface atm 0.1 

ip address 138.108.168.3 255.255.255.0 
atm esi-address 333033303330.00 
map-group ip-routerC 

map-group ipx-routerC 


map-list ip-routerC 
ip 131.108.168.1 atm-nsap 47.000100010001000100010001 .111011101110.00 broadcast 
ip 131.108.168.2 atm-nsap 47.000200020002000200020002 .222022202220.00 broadcast 


map-list ipx—-routerC 

ipx 100.0000.0000.0001 atm-nsap 47.000100010001000100010001.111011101110.00 
broadcast 

ipx 100.0000.0000.0002 atm-nsap 47.000200020002000200020002 .222022202220.00 
broadcast 


Summarizing, the syntax of the SVC commands for RFC 2684 is as follows: 


Router (config-if)# atm nsap-address nsap-address 


or 


Router (config-if)# atm esi-address esi 

Router (config-if) # map-group name 

Router (config)# map-list name 

Router (config-map-list)# protocol protocol-address atm-nsap atm-nsap-—address 
[class class-—name] [broadcast ] 


Table 8-6 summarizes all the parameters that are used for configuring router 
interconnectivity through the SVC- based ATM networks. 


Table 8-6. Argument Description of the SVC-Associated Commands 


| Argument | Description 
nsap-address [Source address, specified as 40 hexadecimal digits. 


esi End-station system identifier (esi), specified as 12 
hexadecimal digits. To form a full NSAP address, the 26 
hexadecimal-digit prefix is learned dynamically from the 
ingress ATM switch with help of ILMI. 
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name The name of the map list that is created at the global 
configuration mode. The map list name must be 
referenced from the interface/subinterface mode by using 
map- group to activate the map list. 

protocol One of the following keywords: ip, ipx, appletalk, 


decnet, vines, apollo, and so on, depending on the 
Layer 3 protocol in use. 


|protocol-address [Destination address that is being mapped to this SVC. 


ereeP (Destination ATM NSAP address. 
address 


class-name A reference to the traffic parameters map class lists. This 
is optionally available to change the traffic parameter 
values from their default values. With the help of map- 
class statements, you can customize the traffic-shaping 
parameters for various types of traffic. 


broadcast Keyword that is necessary if protocol broadcast traffic, 

like routing updates, needs to use the ATM interface. 
Table 8-5 is excerpted from Cisco ATM Solutions, Galina Diker Pildush, Cisco 
Press. 


Cisco |OS Software extends traffic-shaping capabilities to SVCs with the help of map-class 
commands: 


Router (config-map-class) # atm forward-peak-cell-rate-clp0O rate 
atm backward-peak-cell-rate-clp0O rate 

atm forward-peak-—cell-rate-clpl rate 

atm backward-peak-cell-rate-clpl rate 

atm forward-sustainable-cell-rate-clp0O rate 
atm backward-sustainable-cell-rate-clp0O rate 
atm forward-sustainable-cell-rate-clpl rate 
atm backward-sustainable-cell-rate-clpl rate 
atm forward-max-burst-size-clp0O cell-count 
atm backward-max-burst-size-clp0O cell-count 
atm forward-max—-burst-size-clpl cell-count 
atm backward-max-burst-size-clpl cell-count 


The map class is referred to from the map list level by using the class command within the 
map list, as illustrated in Example 8-5. 


Example 8-5 Example of Traffic Engineering Deployment in SVC 


Router (config) # map-class atm contract-svcs 

Router (config-map-class) # atm forward-peak-cell-rate-clp0O 56000 

Router (config) # map-list test ip 200.0.0.1 atm-—-nsap 
44.444400000000000000000000.000000000000.00 class contract-svcs 
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Configuring RFC 2225 (Classical IP) 


Classical IP, specified in RFC 2225, is a dynamic method of IP interconnectivity through the 
ATM network. Classical |P uses RFC 2684 encapsulation. It provides a dynamic method for IP 
interconnectivity through the ATM network, freeing you from the necessity of configuring 
Manually intensive mapping statements. Here is my definition of Classical | P: 


It internetworks IP only. It allows native "behavior" of |P through the ATM 
cloud. This implies that the IP ARP function of mapping IP addresses to the 
ATM PVCs or SVCs happens dynamically. The dynamics occur with the help of 
ARP server for the SVC scenario; in the case of PVCs, InATMARP must be 
configured for every PVC defined. The SVC scenario does not provide for 
redundancy, per the specification. Cisco has a proprietary solution to provide 
for redundancy. RFCs 1577 and 2225 specify the IP interoperability within a 
single network/subnetwork (or you can refer to it as a broadcast domain). 


Classical IP utilizes a client/server architecture, which helps the ATM cloud pretend that it is a 
broadcast domain. Recall that IP ARP is a local broadcast. Because ATM is a nonbroadcast 
domain, deployment of the client/server architecture solves the problem. All the clients 
connect to the server, and the server performs the ARP function. 


Notice that only SVC-based ATM networks deploy a client/server architecture. The PVC-based 
ATM networks do not require it. This is because PVC-based ATM networks have VCs pre- 
established and deploy locally significant ATM addressing. PVC-based ATM deploy |nATMARP 
to resolve VCs identifiers to the corresponding IP addresses, without involvement of an ARP 
server. This is exactly how InARP Frame Relay operates as well. 


Please note that the original Classical |P specification, RFC 1577, does not specify ARP server 
redundancy. Cisco has had a proprietary solution to provide server redundancy prior to 
release of RFC 2225, which provisions for ARP server redundancy. 


For more information on the theoretical part of Classical IP, refer to the Cisco ATM Solutions 
book. 


Now let's look at the configuration examples for PVC- and SVC-based ATM networks. 
PVC Implementation 


Classical IP implementation through the use of PVCs uses INATMARP, which dynamically 
announces to the edge devices the IP addresses that are associated with the predefined 
PVCs. As a result, the edge devices build a dynamic ARP table between their IP addresses 
and the corresponding PVCs' VCD numbers. 


Each router, A, B, C, and D, dynamically builds a table by using InATMARP. The table 
associates the IP addresses with the locally significant VCD numbers, as listed in Table 8-7. 


Table 8-7. Dynamic |P and VCD Number Assignment 


579 


IP Address VCD Number 
138.108.168.2 
138.108.168.3 
138.108.168.4 
138.108.168.1 
138.108.168.3 
138.108.168.4 
138.108.168.1 
138,106,168:2 
138.108.168.4 
138.108.168.1 
138.106,163.2 
138.108.168.3 


| Router 


The syntax of PVC commands for Classical IP is identical to that of the regular PVC 
commands. You need to create PVCs as you would when implementing RFC 2684. Only two 
differences exist. You need to specify inarp at the end of the atm pvc command, and you 
have to omit the map-group statement that is referencing the corresponding map list. Table 
8-4 provides all the details of the PVC command components. 


Let's examine the network illustrated in Figure 8-5. You have four routers interconnected 
across the ATM network. The identified VCD values enable a fully meshed topology, which 
results in a direct VC availability from any to any router. 


Figure 8-5. Classical |P over PVC-Based ATM Network 


Router A Router B 


Router D 7 Router C 
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Example 8-6 presents the configuration for all routers. 


Example 8-6 Classical |P Implementation Using PVC-Based ATM 
Network 


Router A (config)# interface atm 0 

no shutdown 

interface atm 0.1 

ip address 138.108.168.1 255.255.255.0 
atm pvc 12 0 77 aal5snap inarp 5 

atm pvc 13 0 78 aal5snap inarp 5 

atm pvc 14 0 79 aal5snap inarp 5 


Router B (config)# interface atm 0 

no shutdown 

interface atm 0.1 

ip address 138.108.168.2 255.255.255.0 
atm pvc 21 0 87 aal5snap inarp 5 

atm pvc 23 0 88 aal5snap inarp 5 

atm pvc 24 0 89 aal5snap inarp 5 


Router C (config)# interface atm 0 

no shutdown 

int atm 0.1 

ip address 138.108.168.3 255.255.255.0 
atm pvc 31 0 97 aal5snap inarp 5 

atm pvc 32 0 98 aal5snap inarp 5 

atm pvc 34 0 99 aal5snap inarp 5 


Router D (config)# interface atm 0 

no shutdown 

int atm 0.1 

ip address 138.108.168.4 255.255.255.0 
atm pvc 41 0 107 aal5snap inarp 5 

atm pvc 42 0 108 aal5snap inarp 5 

atm pvc 43 0 109 aal5snap inarp 5 


All the routers are configured to send Inverse ARP datagrams every 5 minutes. 
SVC Implementation 


Implementing Classical |P over SVC-based ATM networks is based on a client/server 
architecture. This implies that there must be a server providing services to many clients. 
Classical IP provisions one ARP server, called ATMARP server, for many clients within a single 
broadcast domain. No longer do you have to configure static mapping between the globally 
significant ATM addresses and IP addresses—the ATMARP server takes care of it dynamically. 


The simplicity of the architecture provides for little configuration in both ATMARP server and 
clients. All you have to do is assign either your full ATM address or the ESI prefix only (in this 
case, each router learns the prefix dynamically from an ingress ATM switch) in both clients 
and servers. Then, clients have to specify the full ATM address of the ATMARP server. All 
clients and a server must have the signaling and the ILMI PVCs. Then, the magic begins. 
Clients, knowing the ATMARP server address, automatically announce themselves to the 
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server. In turn, when the client/server VC is set, the server builds the dynamic ARP table, 
containing the cross-reference between the clients' |P and ATM addresses. 


Figure 8-6 illustrates a sample Classical |P setup, where all four routers share one IP 


network, 138.108.168.0, across the ATM cloud. Router B is the ATMARP server, and routers 
A, C, and D are the clients. 


Figure 8-6. Classical |P over SVC-Based ATM Network 
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Client Client 
47.000400040004000400040004.444044404440.00 = 47,000300030003000300030003.333033303320.00 


After you define the clients, each one sets up a VC to the ATMARP server, Router B. Then, 
each client sends ATMARP request packets to the ATMARP server. The server, Router B, 
examines each ATMARP request packet and uses the information to build its ATMARP cache. 
This information is a dynamic cross-reference between the clients' ATM and IP addresses, as 
defined in Table 8-8. Using the ARP table entries, clients can communicate with each other 
without the need for static map list entries. 


Table 8-8. Dynamically Generated ATMARP Server Cache Entries 


| IP Address | ATM (NSAP) Address 

/138.108.168.1 oe 
[138.108.168.2 47.000200020002000200020002.222022202220.00 
/138.108.168.3 [47.000300030003000300030003.333033303330.00 
/138.108.168.4 [47.000400040004000400040004.444044404440.00 


Example 8-7 depicts the configurations that are required in all four routers (routers A, C, and 
D are clients; Router B is the ATMARP server). Notice that static mapping no longer is 
required. 
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Example 8-7 Classical |P Implementation Using ATM SVC-Based 
Network 


Router A (config)# interface atm 0 

atm pvc 1 0 5 qsaal 

no shutdown 

interface atm 0.1 

ip address 138.10.168.1 255.255.255.0 

atm nsap-address 47.000100010001000100010001.111011101110.00 
atm arp-server nsap 47.000200020002000200020002 .222022202220.00 


Router B (config)# interface atm 0 

atm pvc 1 0 5 qsaal 

no shutdown 

interface atm 0.1 

ip address 138.108.168.2 255.255.255.0 

atm nsap-address 47.000200020002000200020002 .222022202220.00 
atm arp-server self 


Router C (config)# interface atm 0 

atm pvc 1 0 5 qsaal 

no shutdown 

interface atm 0.1 

ip address 138.108.168.3 255.255.255.0 

atm nsap-address 47.000300030003000300030003 .333033303330.00 
atm arp-server nsap 47.000200020002000200020002 .222022202220.00 


Router D (config)# interface atm 0 

atm pvc 1 0 5 qsaal 

no shutdown 

interface atm 0.1 

ip address 138.108.168.4 255.255.255.0 

atm nsap-address 47.000400040004000400040004 . 444044404440 .00 
atm arp-server nsap 47.000200020002000200020002 .222022202220.00 


Example 8-7 uses a single ATMARP server within a broadcast domain. If you need ATMARP 
server redundancy, you need to define more than one ATMARP server in every client, as 
illustrated in Example 8-8, using Figure 8-7. The second ATMARP server is Router D. 


Figure 8-7. Redundant ATMARP Server Classical IP over SVC-Based 
ATM Network 
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Example 8-8 Redundant ATMARP Server Classical | P |! mplementation 
Using ATM SVC-Based Network 


Router A (config)# interface atm 0 

atm pvc 1 0 5 qsaal 

no shutdown 

interface atm 0.1 

ip address 138.108.168.1 255.255.255.0 

atm classic-—ip-extensions bfi 

atm nsap-address 47.000100010001000100010001 .111011101110.00 
atm arp-server nsap 47.000200020002000200020002 .222022202220.00 
atm arp-server nsap 47.000400040004000400040004 .444044404440.00 


Router B (config)# interface atm 0 

atm pvc 1 0 5 qsaal 

no shutdown 

interface atm 0.1 

ip address 138.108.168.2 255.255.255.0 

atm classic-ip-extensions bfi 

atm nsap-address 47.000200020002000200020002 .222022202220.00 
atm arp-server nsap 47.000400040004000400040004 ..444044404440.00 
atm arp-server self 

Router C - Client 


Router C (config)# interface atm 0 

atm pvc 1 0 5 qsaal 

no shutdown 

interface atm 0.1 

ip address 138.108.168.3 255.255.255.0 

atm classic-—ip-extensions bfi 

atm nsap-address 47.000300030003000300030003 .333033303330.00 
atm arp-server nsap 47.000200020002000200020002 .222022202220.00 
atm arp-server nsap 47.000400040004000400040004 ..444044404440.00 
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Router D (config)# interface atm 0 

atm pvc 1 0 5 qsaal 

no shutdown 

interface atm 0.1 

ip address 138.108.168.4 255.255.255.0 

atm classic-—ip-extensions bfi 

atm nsap-address 47.000400040004000400040004 .. 444044404440 .00 
atm arp-server nsap 47.000200020002000200020002 .222022202220.00 
atm arp-server self 


Notice the use of the new atm classic-ip-extensions bfi command, which allows the 

ATMARP server redundancy. Initially, clients Router A and Router C use Router B as their 
ARMARP server. If Router B becomes unavailable, the clients use Router D as their backup 
ATMARP server. 


Classical IP implementation enables you to define only the ESI portions of the ATM addresses 
at the clients and the server, which then uses ILMI to obtain the prefix portion of their NSAP 


addresses from the corresponding ingress ATM switches. 


Summarizing, the syntax for the clients' Classical IP implementation over SVC-based ATM 
networks is as follows: 


Router (config) # int atm int# 
Router (config-if)# atm pve vcd# vpi# 5 qsaal 


And, if the ESI portion of the address is used: 
Router (config-if)# atm pve vcd# vpi# 16 ilmi 


Router (config) # int atm subint# 
Router (config-if)# atm nsap nsap-address 


or: 


Router (config-if)# atm esi esi-portion-address 
Router (config-if)# atm arp-server nsap nsap-address 


The syntax for the ATMARP server implementation is as follows: 


Router (config) # int atm int# 
Router (config-if)# atm pve vcd# vpi# 5 qsaal 


And, if the ESI portion of the address is used: 
Router (config-if)# atm pve vcd# vpi# 16 ilmi 


Router (config) # int atm subint# 
Router (config-if)# atm nsap nsap-address 


or: 


Router (config-if)# atm esi esi-portion-address 
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Router (config-if)# atm arp-server self [time-out minutes] 


The atm arp-server self command declares to the router that it is the ATMARP server. The 
time-out, specified in minutes, is optional. It identifies the number of minutes that a 
destination entry listed in the ARP cache is kept before the server takes any action to verify 
the address. The default value of the ATMARP cache timeout is 20 minutes, per RFC 2225. 


586 


Lab 18: Configuring PVCs on Cisco 7XXX Routers, RFC 2684—Part | 


Practical Scenario 


Unfortunately for ATM, most of ATM's implementations are PVC-based. The reason | say 
"unfortunately" is because SVC-based networks are simpler to set up. Also, dynamic ATM QoS is 
available with SVC-based networks only. Knowing the steps involved in PVC-based ATM networks 
setup is one of the prerequisites for the CCIE examination lab. 


Lab Exercise 


You are running an IP-based network, which extends through the ATM cloud. You must 
interconnect various sites. The ATM network is PVC-based. Your service provider promised to give 
you all the necessary addressing to interconnect your five sites. You are running the EIGRP 
routing protocol. You need to maintain the following guidelines in your implementation: 


e Use EIGRP as the routing protocol with autonomous system 100. 
e Assign proper VPI/VCI numbers to all the PVCs. 
e Maintain a fully meshed topology. 


Lab Objectives 


At the end of this lab, you will complete the following: 


e Configure the Cisco router for operation. 
e Configure a full mesh PVC environment. 
e Configure RFC 2684. 


Equipment Needed 


The lab uses five routers and one ATM switch. For CCIE preparation, it is sufficient to obtain two 
routers interfacing through the ATM network. To summarize, you need the following equipment: 


e At least five routers with ATM interfaces 
e OneLS1010 ATM switch 


Physical Layout and Prestaging 
e Connect the routers to the ATM switch, as shown in Figure 8-8. 


Figure 8-8. PVCs for IP 
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PVCs - Lab #1, RFC 2684 
Interaoe ATMA. 1 


Note that, although Figure 8-8 shows five routers, you can perform a similar exercise by 
using only two routers interconnected through the ATM network. 
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Lab 18: Configuring PVCs on Cisco 7XXX Routers, RFC 2684— 
Part Il 


Lab Walkthrough 


You need to configure the IP routing protocol and IP addressing, which are used in both labs. 
After the initial configuration is complete, you need to set up eight PVCs to the other routers, 
creating a fully meshed topology. Your IP connectivity must extend through the ATM network. 


Table 8-9 lists the commands that you need to complete this lab. 


Table 8-9. Lab Command Summary 


| Command | Description 

router eigrp Turns on the EIGRP routing protocol on the router 
latm pvc Sets up bidirectional permanent virtual circuits 
imap-list [Maps a Layer 3 network address to a PVC 


Displays the configured virtual circuits on the 
show atm vc nes 


show atm interface 


pane Displays more detail about the specified interface 


Displays the map-lists that were created by the 


show atm map weer 


Debug atm events Displays the creation of PVCs between the router 
and the ATM switch 


show ip route Displays the IP routing table 
ping Tests connectivity at Layer 3 


Refer to Figure 8-8 to complete the following exercises for this lab. 
Step 1. Configure the Router Parameters 


Configure your router with the following parameters: 


Host name: Rn (where n is the router number) 
Enable password: atmlab 

Virtual terminal/console password: cisco 

IP routing: ElIGRP 

EIGRP autonomous system number: 100 

IP as your only routed protocol 


Example 8-9 shows the configuration for R1. 
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Example 8-9 Router R1 Configuration Parameters 


Rl (config) # hostname R1 
! 
enable password atmlab 
! 


router eigrp 100 
network 165.128.0.0 
! 

line con 0 
exec-timeout 0 0 
line aux 0 

line vty 0 4 
exec-timeout 0 0 
password cisco 
login 

! 


Step 2. Configure the IP Addresses for the Ethernet 0 and ATM 1/0.1 Interfaces 
Configure the IP addresses for the Ethernet 0 and ATM 1/0.1 interfaces with the IP 


addresses, as identified in Table 8-10. 


Table 8-10. 1P Address Assignment 


| Router | EO | ATM1/ 0.1 
IR1 165. 128.1.1/24 165.128.100.1/24 
IR2 165. 128.2.2/24 165.128.100.2/24 


IR3 165.128.3.3/24 165.128.100.3/24 
IR4 165.128.4.4/24 165.128.100.4/24 
IR5 [165.128.5.5/24 [165.128.100.5/24 


Example 8-10 shows the configuration for R1. 


Example 8-10 | P Address Configuration for Router R1 


Rl (config) # interface e0 

ip address 165.128.1.1 255.255.255.0 
interface atm1/0.1 multipoint 

ip address 165.128.100.1 255.255.255.0 


Step 3: Configure a PVC to Every Other Router 


To create a fully meshed ATM PVC network, you need to configure a PVC to every other 
router. Use AAL5SNAP. Use Table 8-11 for the VPI/VCI number assignment. 
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Table 8-11. VPI/ VCI Assignment 


| From | To | CD 
a ce, (ee 
—__ OS 

ee 
eS Sa es ee | 


_ as 
—_ 


R4 


Example 8-11 shows the configuration for R1. 


Example 8-11 PVC Configuration for Router R1 


R1 (config) # interface atm1/0.1 multipoint 
ip address 165.128.100.1 255.255.255.0 
atm pve 112 0 112 aal5snap 
atm pvc 113 0 113 aal5snap 
atm pvc 114 0 114 aal5snap 
atm pvc 115 0 115 aal5snap 


Step 4: Configure LS1010 to Handle PVCs 


In the CCIE lab, the ATM switch is preconfigured. For your CCIE preparation, however, you 
are required to configure your own switch, as demonstrated in Example 8-12. The 
configuration is as follows. 


Example 8-12 Configuring an ATM Switch to Be PVC-Aware 
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ATM-Switch# version 11.3 


no service pad 


no service udp-small-servers 
no service tcp-small-servers 


hostname ATM-Switch 


enable password atmlab 


no ip domain—lookup 


atm address 47.0091.8100.0000.0010.0739.a101.0010.0739.a101.00 
atm router pnni 


node 1 level 56 lowest 
redistribute atm-static 


interface ATMO/1/0 
no ip address 


no atm auto-configuration 


atm uni version 3.1 
atm maxvpi-bits 3 

atm maxvci-bits 10 
interface ATMO/1/1 0 121 
interface ATMO/1/2 0 131 
atm pvc 0 114 interface ATMO/2/0 0 141 
atm pvc 0 115 interface ATMO/2/1 0 151 


atm pvc 0 
atm pvc 0 


112 
113 


interface ATM0/1/1 
no ip address 


no atm auto-configuration 


atm uni version 3.1 
atm maxvpi-bits 3 
atm maxvci-bits 10 


atm pvc 0 
atm pvc 0 
atm pvc 0 
atm pvc 0 


121 
123 
124 
125 


interface 
interface 
interface 
interface 


interface ATM0/1/2 
no ip address 


no atm auto-configuration 


atm uni version 3.1 
atm maxvpi-bits 3 
atm maxvci-bits 10 


atm pvc 0 
atm pvc 0 
atm pvc 0 
atm pvc 0 


131 
132 
134 
135 


interface 
interface 
interface 
interface 


interface ATM0/2/0 
no ip address 


no atm auto-configuration 


atm uni version 3.1 
atm maxvpi-bits 3 
atm maxvci-bits 10 
atm pvc 0 141 


ATM0/1/0 
ATMO/1/2 
ATM0/2/0 
ATM0/2/1 


ATM0/1/0 
ATMO/1/1 
ATM0/2/0 
ATMO/2/1 


ooo°o 


ooo°o 


112 
132 
142 
152 


113 
123 
143 
153 


interface ATMO/1/0 0 114 
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atm pvc 0 142 
atm pvc 0 143 
atm pvc 0 145 


interface 
interface 
interface 


interface ATM0/2/1 
no ip address 


no atm auto-configuration 


atm uni version 3.1 
atm maxvpi-bits 3 
atm maxvci-bits 10 


atm pvc 
atm pvc 
atm pvc 


atm pvc 
! 


0 


0 
0 
0 


151 
152 
153 
154 


interface 
interface 
interface 
interface 


interface Ethernet2/0/0 


ip address 10.0.0.12 255. 


ip classless 


line con 


0 


exec-timeout 0 0 
password cisco 


login 
line aux 


0 


line vty 0 4 
exec-timeout 0 0 
password cisco 


login 
! 


end 


Step 5: Map Your Neighbor's IP Network Number to the Appropriate PVC 


Example 8-13 uses R1 to demonstrate this step of the lab. 


Example 8-13 Mapping | P Network Numbers to the Proper PVC 


QO. 


ATMO/1/1 
ATM0/1/2 
ATMO/2/1 


ATM0/1/0 
ATM0O/1/1 
ATMO/1/2 
ATM0/2/0 


0.0 


ooo0o°o 


124 
134 
154 


115 
125 
135 
145 


R1 (config) # interface atm1/0.1 multipoint 
ip address 165.128.100.1 255.255.255.0 
atm pvc 112 0 
atm pvc 113 0 
atm pvc 114 0 
atm pvc 115 0 
map-group ip-Pvc 


map-list ip-Pvc 
ip 165.128.100 
ip 165.128.100 
ip 165.128.100 
ip 165.128.4100 


112 
113 
114 
115 


2 atm-vc 
3 atm-vc 
4 atm-vc 
5 atm-vc 


aal5snap 
aal5snap 
aal5snap 
aal5snap 


Step 6: Test Your Configuration 


112 broadcast 
113 broadcast 
114 broadcast 
115 broadcast 
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Lab 19: Configuring Classical IP Using SVCs on Cisco 7XXX Routers, 
RFC 2225—Part | 


Practical Scenario 


Classical IP reduces many configuration steps, such as the necessity to perform manual mapping 
between Layer 3 addressing and ATM. This lab demonstrates the use of SVCs as well. 


Lab Exercise 


You are running an IP-based network that extends through the ATM cloud. You must interconnect 
various sites. The ATM network is SVC-based. Your service provider is not giving the details of 
SVC addressing. Therefore, you decided to learn the address prefixes from the provider's ingress 
ATM switch by using ILMI. Furthermore, you want to use Classical IP. You are running the EIGRP 
routing protocol. You need to maintain the following guidelines in your implementation: 


Use EIGRP as the routing protocol with autonomous system 100. 
Assign ESI portions of the NSAP address. 

Establish signaling and ILMI PVCs. 

Assign the ATM ARP server function to R2. Other routers are clients. 
Maintain a fully meshed topology. 


Lab Objectives 


At the end of the lab, you will complete the following: 


e Enable Classical IP of the SVC network (RFC 2225). 
e Configure the ARP server and client (RFC 2225). 
e Implement a single logical |P subnet (LIS). 


Equipment Needed 


The lab uses five routers and one ATM switch. For CCIE preparation, it is sufficient to obtain two 
routers interfacing through the ATM network. To summarize, you need the following equipment: 


e At least five routers with ATM interfaces 
e OneLS1010 ATM switch 


Physical Layout and Prestaging 
e Connect the routers to the ATM switch, as shown in Figure 8-9. 


Figure 8-9. Classical IP 
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PYCs - Lab #2, APG 22225 
Intertace AT RATS 


165 1281 ees 
a 165.128 200 04 


(GS, 128. SOs 


ATM Network 


165,128,400 
165.1283) EO 


e Note that although Figure 8-9 shows five routers, you can perform a similar exercise by 
using only two routers interconnected through the ATM network. 


Figure 8-9 illustrates the network diagram and addressing scheme used in this lab. 
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Lab 19: Configuring Classical IP Using SVCs on Cisco 7XXX 
Routers, RFC 2225—Part Il 


Lab Walkthrough 


You use the same IP addressing and IP routing protocol as you used in the previous lab. The 
steps necessary to perform these tasks are presented here for your reference. The ATM 
network is SVC-based. Your IP connectivity must extend through the ATM network, creating a 
fully meshed environment. 


This lab illustrates the extension of |P connectivity using Classical |P. In addition to Classical 
IP implementation, you use ILMI for a dynamic ATM address prefix assignment. 


Table 8-12 lists and describes the commands that are necessary to complete this lab. 


Table 8-12. Lab Command Summary 


| Command | Description 
jatm pvc [Used for signaling and ILMI PVCs creation 
latm arp-server self ‘Configures the ARP server for one LIS 


AE ATP Set VEE Configures the ARP server client 
eae | 


Configures the ATM ESI portion of the NSAP (AESA) 
address 


debug atm events als the creation of PVCs between router and 


debug atm arp [Shows ATM ARP events 
show ip route [Shows the IP routing table 
ping Tests connectivity at Layer 3 


Refer to Figure 8-9 to complete the steps described in the sections that follow. 


atm esi-address 


Step 1. Configure the Router Parameters 


Configure your router with the following parameters: 


Host name: Rn (where n is the router number) 
Enable password: atmlab 

Virtual terminal/console password: cisco 

IP routing: ElGRP 

EIGRP autonomous system number: 100 

IP as your only routed protocol 
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Example 8-14 shows the results of your configuration, demonstrated for R1. 


Example 8-14 Configuring the Router Parameters 


Rl (config) # hostname R1 
! 
enable password atmlab 
! 


router eigrp 100 
network 165.128.0.0 
! 

line con 0 
exec-timeout 0 0 
line aux 0 

line vty 0 4 
exec-timeout 0 0 
password cisco 
login 

! 


Step 2. Configure the IP Addresses for the ATM 1/0.2 Interfaces 


Configure the IP addresses for the ATM 1/0.2 interfaces with the IP addresses identified in 
Table 8-13. 


Table 8-13. 1P Address Assignment 


| Router ATM1/ 0.1 


Rl 165.128.200.1/24 


IR2 Pees 
IR3 165.128.200.3/24 
IR4 [165.128.200.4/24 
IR5 [165.128.200.5/24 


Example 8-15 shows the configuration for R1. 


Example 8-15 IP Address Configuration for Router R1 


R1 (config) # interface atm1/0.2 multipoint 
ip address 165.128.200.1 255.255.255.0 


Step 3: Configure Two PVCs—Signaling and ILMI on the Major Interfaces on Every 
Router 


Example 8-16 shows how to perform the configuration for this step on Router 1. 
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Example 8-16 Configuring the Signaling and ILMI on PVCs 


Rl (config) # interface atm1 

atm pvc 1 0 5 qsaal 

atm pvc 2 0 16 ilmi 

interface atm 1/0.2 multipoint 

ip address 165.128.200.1 255.255.255.0 


Step 4: Configure LS1010 to Handle PVCs 


In the CCIE lab, the ATM switch is preconfigured; However, for your CCIE preparation, you 
are required to configure your own switch as demonstrated in Example 8-17. The 
configuration is as follows. 


Example 8-17 Configuring an ATM Switch to Be PVC-Aware 


ATM-Switch# version 11.3 
no service pad 
no service udp-small-servers 
no service tcp-small-servers 
! 
hostname ATM-Switch 

! 
enable password atmlab 

! 
no ip domain-—lookup 

! 
atm address 47.0091.8100.0000.0010.0739.a101.0010.0739.a101.00 
atm router pnni 

node 1 level 56 lowest 

redistribute atm-static 
! 
interface ATM0/1/0 

no ip address 

no atm auto-configuration 
atm uni version 3.1 

! 
interface ATMO/1/1 

no ip address 

no atm auto-configuration 
atm uni version 3.1 

! 
interface ATMO/1/2 

no ip address 

no atm auto-configuration 
atm uni version 3.1 

! 
interface ATM0/2/0 

no ip address 

no atm auto-configuration 
atm uni version 3.1 

! 
interface ATMO/2/1 

no ip address 
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no atm auto-configuration 
atm uni version 3.1 


Step 5: Assign the ESI Portion of the NSAP Address to Router Interfaces 


This step involves assigning the ESI portion of the NSAP address to the interface atm1/0.2 of 
all the routers, using Table 8-14. 


Table 8-14. 1P Address Assignment 


| Router | ESI Portion of the Address 
IR1 a ee 
IR2 0002.0002.0002.00 
IR3 (0003.0003.0003.00 


IR4 0004.0004.0004.00 
IR5 0005.0005.0005.00 


Example 8-18 shows the configuration for this step by using R1. 


Example 8-18 Mapping the ESI Portion of the NSAP Address to the 
atm1/ 0.2 Interface 


Rl (config) # interface atm1 

atm pvc 1 0 5 qsaal 

atm pvc 2 0 16 ilmi 

interface atm 1/0.2 multipoint 

ip address 165.128.200.1 255.255.255.0 
atm esi-address 0001.0001.0001.00 


Step 6: Define the Address of the ATM ARP Server 


This step involves defining the address of the ATM ARP server in R1, R3, R4, and R5, and 
defining R2 to be the ATM ARP server. 


R2 is the ATM ARP server that is consulted by R1, R3, R4, and R5 to resolve between IP and 
ATM addresses. Example 8-19 shows how to configure R2 as the ATM ARP server. 


Example 8-19 Configuring R2 as the ATM ARP Server 


R2 (config) # interface atm1 

atm pvc 1 0 5 qsaal 

atm pvc 2 0 16 ilmi 

interface atm 1/0.2 multipoint 

ip address 165.128.200.2 255.255.255.0 
atm esi-address 0002.0002.0002.00 

atm arp-server self 
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R1, R3, R4, and R5 are the clients. The configuration of a client must have the ATM ARP 
server NSAP address. Example 8-20 shows the configuration of a client by using R1 as the 


example. 


Example 8-20 Configuring the ATM ARP Server Clients 


Rl (config) # interface atm1 

atm pvc 1 0 5 qsaal 

atm pvc 2 0 16 ilmi 

interface atm 1/0.2 multipoint 

ip address 165.128.200.1 255.255.255.0 

atm esi-address 0001.0001.0001.00 

atm arp-server nsap 47.0091.8100.0000.0010.0739.a101.0002.0002.0002.00 


Notice that the NSAP address of R2 was created using the prefix from the LS1010 and the 
ESI portion that was assigned to R2. 


Step 7: Test Your Configuration 
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Summary 


Cisco supports various router interconnections over ATM networks on its multiple product 
lines, a Summary of which is provided in this chapter. Also, this chapter presents Cisco's 
implementation of multiprotocol encapsulation (RFC 2684) and Classical 1P (RFC 2225) over 
PVC- and SVC-based ATM networks. The chapter provides the syntax of the relevant Cisco 
10S commands, supported by the examples. 


Multiprotocol encapsulation provides interconnectivity of Layer 3 and Layer 2 across the ATM 
networks. The examples in this chapter focus on Layer 3 support. Layer 2 support, LANE, is 
outside the scope of this chapter and is no longer part of the CCIE lab. 


Classical IP (RFC 2225) focuses on IP only and allows dynamic address mapping between IP 
and ATM. 
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Part IV: Routing Protocols 


Routing protocols are the glue of the internetwork. They are the foundation of routers and are 
what has allowed the Internet to grow to its gargantuan size. Your mastery of routing protocols 
is a critical skill in designing and implementing IP networks. The upcoming sections define what 
routing protocols are, give the different types and metrics of each, and compare two major 
classes of routing protocols—distance vector protocols and link-state protocols. 


Part IV includes the following chapters: 


Chapter 9, "Distance Vector Protocols: Routing Information Protocol Versions 1 
and 2 (RIP-1 and RIP-2)" 


Chapter 10, "Distance Vector Protocols: Interior Gateway Routing Protocol 
(IGRP)" 


Chapter 11, "Hybrid: Enhanced Interior Gateway Routing Protocol (EIGRP)" 


Chapter 12, "Link-State Protocols: Open Shortest Path First" 


What Are Routing Protocols? 


A protocol is a routed protocol if it contains an explicit network address and enough information 
is in its network layer address to allow for a router to make an intelligent forwarding decision. 
Routing is the process by which a packet gets from one network to another. A routing protocol 
supports a routed protocol by providing a means for propagating routing information. This 
information includes elements such as the available routes, a cost to the routes, and the next- 
hop address. The routing protocol uses messages between routers that allow for 
communication with other routers to update and maintain routing tables. It is important to note 
that routing protocols do not carry end-user traffic from network to network. Routing protocols 
only build the paths that end-user data uses to travel. 


The Route Table 


Many routing protocols are in use today. As different as they are from each other, they all 
serve the same purpose of performing routing operations and maintaining a route table. 


The route table contains the following information: 


e Lists of networks/routes or host routes. 

e The means by which the route was learned, either dynamically from a routing protocol 

or statically from manual configuration. 

Administrative distances of the routes. 

The metric or cost of the route. 

The address of the next-hop router to the route. 

The current status of the route. This can include the amount of time since the last 

update, whether the route is in holddown, and so forth. 

e The interface associated with reaching the route. This is the interface from which the 
packet will be forwarded to the next-hop router. 


Example IV-1 depicts a complex routing table, illustrating OSPF, EIGRP, and default routing. 


Example IV-1 Routing Table 


r2#show ip route 
Codes: C -— connected, S - static, I - IGRP, R - RIP, M — mobile, B - BGP 
D — EIGRP, EX — EIGRP external, O - OSPF, IA —- OSPF inter area 
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N1 —- OSPF NSSA external type 
El - OSPF external type 1, E 
i - IS-IS, Ll - IS-IS level- 
U - per-user static route, o 


Gateway of last resort is 172.16.12 


10.0.0.0/24 is subnetted, 1 su 
O 10.10.10.0 is a summary, 03 
129.201.0.0/24 is subnetted, 1 
© El 129.2010 21.10 [10/90] wae 17 
128.200.0.0/24 is subnetted, 1 
D EX 128.200.1.0 [170/679936] vi 
129.200.0.0/24 is subnetted, 1 
QO: Bi 129.200.1.0 [110/90] via 17 
128.201.0.0/24 is subnetted, 1 
D EX 128.201.2100 [170/679936) wi 
GC 201.201.101.0/24 is directly c 
O-E2 132.31.0.0/16 [1110/2] via 172. 
O E2) 131.312.0207 16 [11O/2] vie 172. 
172.16.0.0/16 is variably subn 


O IA 172516.152.0/24 [1i0/71] vi 
O IA 172.16.150.0/24 [110/80] vi 
O IA LIQ. 16.151 50/24. [LLOS 72] sa 
Cc 172.16.144.0/21 is directly 
C 172.16.136.0/21 is directly 
Cc 172.16.128.0/21 is directly 
Cc 172.16.192.0/24 is directly 
Cc 172.16.192.3/32 is directly 
O IA 172:.16.42.2/32 [110/70] via 
O IA 7231624253732 [110/70] vita 
O E2 172.16.42.0/24 [1100/2] via 
O IA 172.16.42.1/32 [110/6] via 
O IA 7251622140724 [iL0/76) wia 
O IA 172.16.22.0/24 [110/71] via 
O E2 L72316.1.00/24 [LL0/2) vie. 1 
O E2 VWI23 16.20/24. [LIO/2) wie: “1 
D 172.16.103.0/24 [90/409600] 
O E2 172.16.84.0/24 [1100/2] via 
O E2 172.16:.85.0/24 [1110/2] via 
O E2 172.16.81.0/24 [1100/2] via 
O E2 172.16.82.0/24 [1100/2] via 
O E2 172.16.83.0/24 [1100/2] via 
O E2 172:.16.64.0/24 [110/2] via 
C 172.16.1.64/26 is directly 
c 172.16:2.64/26 is directly 
D*EX 0.0.0.0/0 [170/20028160] via 1 


You can see many of the routing table components mentioned previously by examining the 
highlighted line. The route 172.16.102.0/24 is being reported by EIGRP. The administrative 
distance of the route is 90, and the EIGRP metric is 67,9936. The route was reported more 
than 5 hours and 42 minutes ago. The next-hop router is over interface Serial1, and its IP 


address is 172.16.192.3. 


The Routing Protocol Algorithm 


All dynamic routing protocols are built around a general algorithm. The routing algorithm 


addresses the following areas: 


1, N2 - OSPF NSSA external type 2 
2 - OSPF external type 2, E - EGP 
1, L2 - IS-IS level-2, 

= (ODR 


8.1 to network 0.0.0.0 


bnets 
£05249, 
subnets 
2.16266; 
subnets 
a 172.162.1923; 
subnets 
216.2266; 
subnets 
a I72.06.092.3, 0S42 257, 
onnected, Loopback0O 
16.2.66, 00:58:04, 
16.2.66, 00:58:04, TokenRingl 
etted, 27 subnets, 4 masks 
a 172.16.2.66, 03705745, TokenRing! 
a 172.16.2.66, 03:05:45, TokenRingl 
a 172.16.2.66, 03:05:45, TokenRingl 
connected, Loopback20 
connected, Ethernetl 
connected, Ethernet0 
connected, Seriall 
connected, Seriall 
172.16.2.66, 03:05:46, 
172:16.2.66, 03:05:46, 
172.16.2.66,. 03205246, 
172.16.2.66, 03:05:46, 
172.16.2.66, 03:05:46, TokenRingl 
172.16.2.66, 03305246, TokenRing! 
T2e16.2.66, 03:05:46, TokenRingl 
72.16.2.66, 03:05:46, TokenRingl 


Nu110 


03:05:45, TokenRingl 


05:42:57, Seriall 


03:05:45, TokenRingl 


Seriall 


TokenRingl 


TokenRingl 

TokenRingl 
TokenRingl 
TokenRingl 


via 172.16.128.1, 05:42:59, Ethernet0O 
172.16.2;.66, 03:05:47, TokenRing! 
172.16.2.66, 03505347, TokenRing1 
172.16..2.66, 03:05:47, TokenRing! 
172.16.2.66,; 03:05:47, TokenRingl 
172.16.2.66, 03:05:47, TokenRingl 
172:16.2.66, 03:05:47, TokenRing! 
connected, TokenRing0O 
connected, TokenRingl 
IZ¢ 16.1281, 05:43:00, 


DNDN DN NY 


Ethernet0O 


* — candidate default 


e A procedure for distributing reachability information about networks to and from other 


routers 


e A procedure for determining and recording optimal routes, based on the reachability 


information received from other routers 
e A procedure to advertise and compensate for topology changes 
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When Does the Router Route? 


By default, all Cisco routers will route all routable protocols, such as IP or |PX, first. If routing 
for the routable protocol is not enabled and bridging for that protocol is enabled, the router will 
bridge it. How a router handles a protocol depends not only on the protocol being a routable 
protocol, but also on how routing is enabled for that protocol. For example, if the router 
receives an |PX packet and has IPX routing enabled, it tries to route or forward the packet to 
the next-hop address. This is the normal operation of |PX. However, if the router receives an 
IPX packet and does not have IPX routing enabled, the router forwards that packet out any 
bridged interfaces, including DLSw ports. This is because the router no longer recognizes | PX 
as a routable protocol. 


To successfully route a packet, a router must know the following: 


e The protocol must be routable, and routing for that protocol suite must be enabled. 

The router must know the destination network or have a default route installed. 

e A valid next-hop address must exist, or an interface pointing at the destination network 
must exist. 


When the decision to route the packet is made, the router checks the packet to see if the final 
destination is a locally connected network. If the destination is local, the router forwards it out 
the appropriate port. If the network is not local, the router must consult the route table. The 
route table consists of known networks, the costs associated with those networks, and the path 
to the next-hop router. The router compares the packet to entries in its route tables by 
performing a longest match lookup. The entry that has the longest match to the destination 
address is the entry used to determine the forwarding path. The longest match route can also 
be referred to as the most explicit route. The longest match is only 100 percent true if ip 
classless is enabled, and it applies mostly to classless routing protocols. 


NOTE 


The longest match lookup occurs when a router must determine which entry in the 
route table to use in forwarding a packet. For example, imagine that the router 
receives a packet that has a destination network of 172.16.1.0/24. It has two 
routes, 172.0.0.0/8 out S1 and 172.16.0.0/16 out S2. Which interface should the 
router forward the packet out? This is when the router performs a longest match 
lookup. To accomplish this, the router compares the bits of the destination 
network, from left to right, with the bits in route in the routing table. The router 
compares each bit in sequence and stops the comparison process at the bit before 
the first bit that doesn't match in the route table entry being compared. The router 
chooses the path/route where the greatest number of consecutive bit matches has 
occurred. In this case, the router uses the 172.16.1.0 route over the 172.16.0.0 
route because the 172.16.1.0 route is the longest match—or, in other words, more 
explicit. 


Routing Metrics 


Another important aspect of routing protocols is to provide a loop-free topology of the network 
while locating the best path to every destination network. Routers advertise the path to a 
network in terms of a metric. The metric value or metric type depends on the routing protocol. 
For example, RIP uses hop count as its metric, whereas OSPF uses cost. The router uses the 
metric value when evaluating multiple paths to the same network. The metrics for all routing 
protocols can be adjusted, thereby influencing which path the router will select in forwarding 
traffic. The following list is a brief description of the most common routing metrics: 


e Hop count— A metric that counts router hops. The more hops, the less desirable the 
path. 


e Bandwidth— A metric that measures bandwidth. The higher the bandwidth, the more 
preferable the path. 604 


e Load— A metric that reflects the amount of traffic on a links to a path. The lower the 
load, the more preferable the path. 


e Delay— A metric that measures the time that a packet takes to traverse a route. The 
lower the delay, the more preferable the route. 


e Reliability— A metric that measures the probability that a link will fail. The higher the 
reliability, the more preferred the path. 


e Cost— A configured metric. The lower the cost, the more preferred the route. 


Because each routing protocol has a unique application of metrics, we will discuss routing 
protocol specific metrics in the upcoming chapters. 


Administrative Distance 


At any given time, more than one routing protocol can be active on a router. The router needs 
a way to classify the routes received from one routing protocol against the routes received 
from another. Cisco uses the concept of administrative distance to measure the trustworthiness 
of the source of IP routing information. The lower the value of the administrative distance is, 
the more preferred the route is. The distance can be changed for each routing protocol with the 
distance command. Table IV-1 lists the default administrative distances of route sources. 


Table IV-1. Default Administrative Distances on Cisco Routers 


Default Administrative 
Distance 


[Connected interface 0 
Static route pointing to an 0 
interface 
Static route to a next-hop 1 
interface 
EIGRP summary route 5 


External BGP 20 
[EI GRP 90 


|GRP 100 


OSPF 110 


IS-1S 115 
RIP-1 and RIP-2 120 


Route Source/ Type 


EGP 140 
External EIGRP 170 
Internal BGP 200 


Unknown route 


Unreachable 


Distance Vector and Link-State Protocols 


Most routing protocols can be divided into two major classes: 
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Distance vector protocols 
Link-state protocols 


Cisco's EIGRP is the exception and is often referred to as a hybrid protocol because it combines 
aspects of link-state and distance vector protocols. EIGRP is closer to a distance vector protocol 
than a link-state protocol because it uses metrics for distance and does not use the link states 
for routing advertisements. 


Distance Vector Protocols 


Distance vector-based algorithms, also known as Bellman-Ford algorithms, pass periodic copies 
of a route table from router to router. Regular updates between routers happen during 
topology changes. Distance vector protocols advertise routes in terms of vectors. Each vector 
has a distance and direction associated with it. For example, in RIP, the subnet 172.10.0.0 is 
the vector, its distance is five hops away, and the direction is the next-hop router. 


Here is a simplistic way of how distance vector protocols operate: 


1. 


At a specific timed interval, the router broadcasts its entire route table out each 
interface. It does not include routes suppressed by filters, split horizons, or routes that 
exist on a different major bit boundary than the interface sending the broadcast. The 
broadcast contains the network or route and a metric associated with that route. 


Each adjacent router receives the update and compares the routes in the update to the 
routes in the route table. The routes with the best metric, the ones with the lower 
metric, are stored in the forwarding table. 


Each adjacent router now propagates its new routing table route to all its neighbors. 


The routers continue to broadcast their route tables to their neighbors at a periodic 
interval. RIP, for example, uses a periodic interval of 30 seconds. 


All distance vector protocols have the following common characteristics: 


Periodic full routing updates— At the end of a certain time limit, usually 10 to 90 
seconds, a full routing table is broadcast to every neighbor. 


Neighbors— Neighbors can be defined as routers sharing a common data link. Distance 
vector routers send updates to all neighbors and depend on them to pass along that 
information to their neighbors. 


Broadcast updates— The router uses a broadcast address to locate its neighbors and 
to advertise its route table. 


Route invalidation timers— These timers provide a means for the router to start to 
degrade the cost of the route and eventually remove it from the route table. The timers 
are reset when a new update is received. 


Split horizon— A route pointing back to the router where it was received is called a 
reverse route. Split horizon prevents reverse routes between routers. The rule of simple 
split horizons states that when sending an update out an interface or subinterface, do 
not include networks learned from that interface. Split horizon is enabled or enforced by 
default on all serial interfaces and subinterfaces. We discuss split horizons more 
throughout the book, especially how this relates to Frame Relay point-to-point and 
multipoint interfaces. 


Maximum hop count or count to infinity— Distance vector networks have a ceiling 
on how many hops a route can be away before the route is declared unreachable. RIP 
has a maximum hop count of 16. 
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e Poison reverse— The rule for poison reverse is to advertise a route out the interface 
on which it was received with an unreachable metric. Different routing protocols employ 
this rule at different times to control routing loops. 


The following is a list of distance vector routing protocols: 


IP Routing Information Protocol (RIP) 

Xerox Networking System's XNS RIP 

IPX RIP 

Cisco's Internet Gateway Routing Protocol (Il GRP) 
DEC's DNA Phase IV 

AppleTalk's Routing Table Maintenance Protocol (RTMP) 
Gateway-to-Gateway Protocol (GGP) 

Exterior Gateway Protocol (EGP) 


Link-State Protocols 


The other class of routing protocols is called link-state protocols. As distance vector protocols 
are based on algorithms by R.E. Bellman, L.R. Ford, and D.R. Fulkerson, link-state protocols 
are based on an algorithm by E.W. Dijkstra. 


Link-state protocols operate in a significantly different manner than that of distance vector 
protocols. Some of the major differences include the following: 


e Support for variable-length subnet masking (VLSM)-— All link-state protocols 
support VLSM. One reason for this is because the routing update includes a subnet 
mask. 


e Neighbors— All link-state environments establish neighbors through the use of a Hello 
protocol. 


e Nonstub routers— Nonstub routers retain a complete map of all paths in the network. 


e Event-triggered routing announcements— Routing updates are propagated by a 
means of flooding link states from one area to the next. The SPF/Dijkstra algorithm 
directs the flooding of LSAs. 


e Link-state database— The link-state database stores link-state advertisements (LSAs) 
as a series of records. The information in the database includes a record of router | Ds, 
connected networks, and adjacent routers, and the cost associated with them. 


e Hierarchical topology required— External areas require connections to backbone 
areas. Link-state networks must be designed around these requirements. OSPF virtual 
links will allow this rule to be broken, but they should be avoided. 


Here is a simplistic way of how link-state protocols operate: 
1. The router establishes an adjacency with each of its neighbors. 


2. Each router sends link-state advertisements (LSAs) or link-state packets (LSPs) to its 
neighbors. One LSA is generated for each route in the table. The LSA identifies the 
route, the state of the route, the cost or metric of the interface associated with the 
route, and any neighbors connected to the route. Each neighbor that receives an 
advertisement forwards it to its neighbors. 


3. Each router stores a copy of all the LSAs that it has received in a database. 


4. The database is called a link-state database. It contains a map or tree of the entire 
network. The router uses the Dijkstra algorithm and calculates a shortest path to each 
network; it enters this information into the routing table. 607 


The most common link-state protocols are as follows: 


Open Shortest Path First (OSPF) for IP 

Intermediate System-to-Intermediate System, for |SO 1S-IS 
DEC's DNA Phase V 

Novell's NetWare Link Services Protocol (NLSP) 


Distance Vector Versus Link-State Routing Protocols 


Table IV-2 highlights the major differences between distance vector and link-state routing 
protocols. 


Table I V-2. 1P Routing Protocol Comparison 
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215 is the distance for an EIGRP summary route. 


The upcoming chapters are intended to be a technical overview of the configuration of RIP, 
IGRP, EIGRP, and OSPF. For a thorough and, in my opinion, one of the best explanations of 
routing protocols, study J eff Doyle's book, Routing TCP/IP, Volumes | and I]. 
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Chapter 9. Distance Vector Protocols: Routing 
Information Protocol Versions 1 and 2 (RIP-1 and RIP-2) 


As IP-based networks enter the 21st century, one of the earliest routing protocols is still 
present in many modern networks. For good reason, RIP has managed to survive from the 
creation of IP to the present. This proves one thing about RI P—despite its limitations, it 
performs its job well. RIP has evolved over the years from a classful routing protocol, RIP 
Version 1 (RIP-1), to a classless routing protocol, RIP Version 2 (RIP-2). This chapter covers 
the operation, configuration, and tuning of RIP-1 and RIP-2, in addition to information on 
route redistribution. 
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Technical Overview of RIP 


RFC 1058 outlines RIP-1, and RFCs 1721, 1722, and 1723 are supplemental RFCs that allow 
for RIP-2 extensions. 


NOTE 


You can find all RFCs online at http://www. isi.edu/in-notes/rfcxxxx.txt, where 
Xxxx iS the number of the RFC. 


RIP operates on UDP port 520—that is, all RIP packets have a source and destination port 
equal to 520. RIP operates in the following manner: 


1. Initialization— When the RIP process initializes, it sends a request packet out each 
participating interface. This request packet asks for a full routing table update from all 
RIP routers. This request is accomplished by broadcasts on LANs and is sent to the 
next-hop address on point-to-point links. The request packet is a special request, 
querying the neighboring devices for a full routing table update. 


2. Request received— RIP has two message types, a response and a receive message. 
Each route entry in the request packet is processed and a metric is formed for the 
route along with the path to the route. RIP uses the hop-count metric. A hop count of 
1 means a directly connected network, whereas a hop count of 16 denotes an 
unreachable network. The entire routing table is sent back as a response received 
message. 


3. Response received— The router receives and processes the response. It can update 
its routing table with the addition, deletion, or modification of entries. 


4. Regular routing updates and timers— Every 30 seconds, the router sends out the 
entire routing table in the form of a response message to every neighboring router. 
The router sets an expiration timer or invalid timer of 180 seconds when a new route 
is received or an update about an existing route is received. If no new update for a 
route is received within 180 seconds, the hop count for the route is set to 16 
(unreachable). The router advertises the route with a metric of 16 until the flush timer 
removes the route from the routing table. The flush timer is set to 240 seconds, or 60 
seconds longer then the expiration timer. Cisco's implementation of RIP, which is not 
defined in RFC 1058, uses a third timer called a hold-down timer. The hold-down 
period occurs for 180 seconds after a route is received with a higher metric. During 
this time, the router does not update its routing table with the new information that it 
received, to provide additional time for convergence. 


5. Triggered routing updates— Whenever a metric for a route changes, the router 
sends only the routes that are affected by the metric change. A full routing table is not 
sent. 


All the timers can be changed with the timers basic update invalid holddown flush command. 


CAUTION 
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When adjusting the timers for RIP, all the timers in the routing domain must also 
be adjusted. Failure to do so can cause many unpredictable results. 


Classful Routing (RIP-1 Only) 


RIP-1 is a classful routing protocol, so it does not advertise a subnet mask along with 
advertised routes. For RIP to determine what the subnet mask is of the destination network, 
RIP uses the subnet mask of the interface in which the route was received. This is true only if 
the route received is a member of a directly connected major network. If the route received is 
not of the same major network, the router tries to match only the major bit boundary of the 
route—either Class A, B, or C. For this reason, it is critical to preserve a consistent bit mask in 
each major network throughout the entire RIP routing domain. 


Figure 9-1 illustrates classful routing on a RIP-1 network. Let's examine how the wolverine 
and rogue routers handle the RIP process. 


Figure 9-1. Classful Routing Example 
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The wolverine router has two interfaces in the 128.200.0.0 major network. The 24-bit mask is 
consistent on every interface on the router. Therefore, the router receives updates only for 
the major network 128.200.0.0 on the 24-bit boundary. When the router receives the update 
out of this major network—for example, 192.16.1.4/30—it enters only a summary route in its 
routing table pointing to the major bit or class boundary of the address, summarizing the 
address to 192.16.1.0/24. Example 9-1 shows the output of debug ip rip demonstrating this 
concept. 


Example 9-1 debug ip rip Command Output on wolverine 
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01:24:39: RIP: sending vl update to 255.255.255.255 via Ethernetl (128.200.1.1) 
O15 24739% subnet 128.200.2.0, metric 1 

01:24:39: RIP: Update contains 1 routes 

01:24:39: RIP: Update queued 

01:24:39: RIP: Update sent via Ethernetl 


: RIP: Update contains 2 routes 
01:24:39: RIP: Update queued 
01:24:39: RIP: Update sent via TokenRing0O 


The rogue router has two interfaces. One is in the 128.200.0.0/16 major network, and the 
other is in the 192.16.1.0/24 network. When the rogue router receives the 128.200.2.0/24 
and 128.200.1.0/24 subnets from its E0/0 interface, it tries to send them out its E0/1 
interface. Because this interface has a different mask (30-bit), only the summary route 
128.200.0.0/16 is sent to the cyclops router. Example 9-2 demonstrates this happening, 
through the aid of debug ip rip. 


Example 9-2 debug ip rip Command Output on rogue 


RIP: 


sending vl update to 255.255.255.255 via Ethernet0/0 (128.200.1.2) 
network 192.16.1.0, metric 1 


Classless Routing (RIP-2 Only) 


RIP-2 is not a new routing protocol, but it is an extension of RIP-1 provided by RFCs 1721, 
1722, and 1723. The extensions provide the following enhancements to RIP: 


e VLSM support. The router carries the subnet mask in the update, which allows the 
router to handle VLSM addressing. 

A next-hop address carried with each route entry. 

Support for external route tags. 

Multicast route updates. 

Support for MD5 authentication. 


The most significant of all the enhancements is the support for VLSM, making RIP-2 a 
classless routing protocol. It is no longer critical to have one bit mask throughout the entire 
routing domain. 


Most of RIP-2 operational procedures and timers are identical to those of RIP-1. RIP-2 uses 
the multicast address of 224.0.0.9 to send updates versus the general all-hosts broadcast 
used by RIP-1. 


RIP-2 is fully backward compatible with RIP-1. This is accomplished by the means of a 
compatibility switch and a receive control switch, as defined in RFC 1723. Essentially, these 
switches allow you to control what type of RIP updates the router sends and receives. The 
router can be configured to receive only Version 1 updates, only Version 2 updates, both, or 
none. The router can send only Version 1 updates, send Version 2 updates as a broadcast 
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message, send Version 2 updates as a multicast, or send no updates. The switches can be 
manually set with the following interface command: 


ip rip [send | receive] version [1 | 2 | 1 2) 
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Configuring RIP-1 and RIP-2 


The configuration of RIP-1 and RIP-2 is a straightforward task: 


Step 1. Enable RIP and the version of RIP on the router. To enable RIP, use the router rip 
global command. At this time, also configure the version of RIP. If you want RIP-1, no 
additional configuration is necessary. For RIP-2, use the version 2 command from the 
config-router# prompt. 


Step 2. Add the networks on which you want to want to run RIP. This is accomplished with 
the command network a.b.c.d from the config-router# prompt. 
Configuring RIP-1 


Example 9-3 illustrates the configuration of RIP-1 on the network previously illustrated in Figure 9-1. 


Example 9-3 RIP-1 Configuration 


hostname wolverine 
! 
router rip 


network 128.200.0.0 
! 


hostname rogue 
! 
router rip 
network 128.200.0.0 


network 192.16.1.0 
! 


hostname cyclops 
! 
router rip 


network 192.16.1.0 
! 


Configuring RIP-2 


Let's update the network from Figure 9-1 to a RIP-2 network. You will configure the Token Ring 


network on wolverine to send and receive both RIP-1 and RIP-2 updates. The Ethernet segment off 
wolverine, however, will send and receive only Version 2 updates. The rogue and cyclops routers will 
be configured to send and receive only RIP-2 updates. Example 9-4 shows the necessary router 
configurations to match this criteria. 


Example 9-4 RIP-2 Configuration 


interface Ethernetl 
ip address 128.200.1.1 255.255.255.0 
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media-type 10BaseT 


interface TokenRingO 
ip address 128.200.2.1 255.255.255.0 


ring-speed 16 


interface Ethernet0/0 
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interface Ethernet0/1 
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interface Ethernet0O 


"o 
'S 
4 
Q. 
a) 
o 
a 
a 
ray 
ie] 
i) 
ay 
f>) 
ray 
>) 
N 
uo 
uo 
N 
uo 
uo 
N 
uo 
uo 
N 
uo 
i) 


Figure 9-2 illustrates the changes in the routing tables after migrating the network to RIP-2. Notice 


how the individual subnets appear on wolverine and cyclops routers. Even though you are now 
sending RIP-2 updates, you must also use the no auto-Summary command to prevent automatic 
summarization at the major class boundary. 


Figure 9-2. Classless Routing Example 
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The "Big show" and "Big D" for RIP 


Troubleshooting RIP can be an easy process. Most of the RIP configuration errors involve a bad 
network statement, discontinuous subnets, or split horizons. Because most of these errors are 
design-related, the debug and show commands for RIP are limited. Again, the list that follows is 
not a complete list; instead, it's a condensed list of what | find to the most useful show and debug 
commands. The "Big show" and the "Big D" commands for RIP are as follows: 


e show ip protocols {summary} 
e show ip route 
e debug ip rip {events} 


show ip protocols {summary} Command 


This command displays all routing protocols, detailed timer and metric information, and routing 
update information. Example 9-5 lists the output of the show ip protocols command. 


Example 9-5 show ip protocols Command Output 


rogue#show ip protocols 
— 


Sending updates every 30 seconds, next due in 29 seconds 


| 


Default version control: send version 1, receive any version 
Interface Send Recv Key-chain 


Btherneto/o 1 2 


Eee 
Routing for Networks: Y~ Networks participating in RIP 
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12:3...200).:0:..0 
Passive Interface(s): 


Routing Information Sources: 
Gateway Distance Last Update 


128.200.1.1 120. 00:00:07 *~ RIP Neighbors 


show ip route Command 


This command lists the router's current routing table and the one on which it makes forwarding 
decisions. It is possible for a route to exist or be known to the router but then have only the routes 
with the shortest administrative distances listed. The output from this command lists what routing 
protocol the route is from—in the case of Example 9-6, R for RIP. The number behind the route is 


the administrative distance of the route followed by the hop count. The Via field explains who the 
route is from, how long ago an update was received, and by what interface. Example 9-6 lists the 


output of the show ip route command used on the rogue router. 


Example 9-6 show ip route Command Output 


rogue#show ip route 
Gateway of last resort is not set 


128.200.0.0/16 is variably subnetted, 4 subnets, 2 masks 


Cc 128.200.1.0/24 is directly connected, Ethernet0/0 

R 128.200.2.0/24 [120/11] via 128.200.1.1, 00:00:17, Ethernet0/0 
€ 128.200.3.16/29 is directly connected, Ethernet0/1 

rogue# 


In this example, the route 128.200.10.0/24 has a metric of 120 and is one hop away. The RIP 
neighbor informing about the route is 128.200.1.1, and it sent the last update 17 seconds ago; 
rogue received it through its Ethernet 0/0 port. 


debug ip rip {events} Command 


This command shows all the RIP activity occurring in the router and also displays exactly which 
interfaces are advertising and receiving routes. The RIP version of the update is also displayed, 
along with the metric of each route in the update. Example 9-7 lists the output of the debug ip rip 


command. Notice that RIP is sending and receiving routes. 


Example 9-7 debug ip rip Command Output 


wolverine#debug ip rip 


sending vl update to 255.255.255.255 via Ethernetl (128.200.1.1) 


1d02h: subnet 128.200.10.0, metric 1 

LAOZH: subnet 128.200.2.0, metric 1 

1d02h: RIP: sending vl update to 255.255.255.255 via TokenRingO (128.200.2.1) 
1do2h: subnet 128.200.10.0, metric 1 

LdO2zhs subnet 128.200.1.0, metric 1 
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Tuning, Redistribution, and Control of RIP Updates 


RIP offers several parameters for tuning timers, controlling broadcasts, and controlling 
routes. The following is a list of some of the common parameters adjustable within RIP: 


Router(config-router)timers basic update invalid holddown flush— This allows the 
user to set the update, invalid, hold-down, and flush timers for RIP. 


Router(config-router) passive-interface interface_name— This command prevents 
the sending of routing updates on a interface; however, the router still listens to 
updates received from that interface. 


Router(config-router) neighbor ip-address— This command defines a RIP neighbor to 
exchange unicast updates with. This command should be used in conjunction with the 
passive-interface command. 


Router(config-router) offset-list [access list_0-99 {in|out} offset [metric_ 
offset_1-16]— Use this command to increase the value of the routing metrics. The 
metric offset cannot exceed 16. 


The following commands are not exclusive to RIP and can be used with other routing 
protocols: 


Router(config-router) distribute-list [1-199] [in | out] [interface]— Use this 
command to call a standard or extended access list to filter inbound or outbound 
routing updates. 


Router(config-router) distance [1-255] adjacent_neighbors_ip address 
wildcard_ mask [access_list_0-99]— Use this command to change the administrative 
distance of routes received from a neighbor. If the IP address and wildcard mask are 
omitted, all routes for that protocol will be set to the distance value. 


Router(config-router) redistribute [connected, static, bgp, igrp, eigrp,ospf, isis] 
{metric} {route-map}— Use this command to redistribute other routing protocols into 
RIP. A route map may be added for additional route control. This sets the metric to be 
used for the redistribution of this specific protocol and the specified autonomous 
system, if the protocol uses one. The other option for setting the redistribute metrics 
is to use the default-metric command discussed in the item that follows. Whenever 
redistributing routes, remember that IP needs a route to and from a destination. Many 
times, mutual redistribution might be required to give IP a path to and from its 
destination. 


Router(config-router) default-metric [1-16]— Use this command to set the default 
metric of all routes redistributed into RIP. You must supply a default metric whenever 
redistributing. 


To see how some of these concepts work, apply some to the existing lab. Figure 9-3 changes 


the subnet between rogue and cyclops to 128.200.3.16/29. Instead of RIP on this segment, 
run EIGRP as the routing protocol. Redistribute between EIGRP and RIP on the rogue router. 
As Figure 9-3 shows, another router, storm, has been integrated into the network. Instead of 


running broadcast updates on the Token Ring segment between the storm and wolverine 
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routers, run unicast updates. 


Figure 9-3. Route Redistribution and Unicast Example 
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To configure RIP unicast between storm and wolverine, you must first use the passive- 
interface command to prevent RIP broadcasts from entering the Token Ring network. Next, 
add a neighbor statement to point to the router in which RIP updates are to be sent. 
Example 9-8 lists the RIP configuration of wolverine and storm. 


Example 9-8 RIP Unicast Configuration 


hostname wolverine 

! 

router rip 

passive-interface TokenRingl 
network 128.200.0.0 
neighbor 128.200.10.2 


hostname storm 

! 

router rip 

passive-interface TokenRing0O 
network 128.200.0.0 
neighbor 128.200.10.1 


The next step is to perform mutual redistribution between EIGRP and RIP on the rogue 
router. Because there is only one redistribution point in the network, there is no need to 
perform any route filtering when using mutual redistribution. To redistribute between El GRP 
and RIP, use the redistribution command, along with adding a default metric. The default 
metric chosen for RIP is 2, whereas 10000 1000 254 1 1500 is the default metric for ElGRP. 
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Because the routing domains overlap (which means that RIP broadcasts will be heard on 
cyclops), use the passive-interface command to prevent excessive broadcasts from 
occurring. Example 9-9 lists the configuration of EIGRP and RIP on the rogue router. 


Example 9-9 EIGRP and RIP Configuration on rogue 


router eigrp 2001 

redistribute rip 
passive-interface Ethernet0/0 
network 128.200.0.0 
default-metric 10000 1000 254 1 1500 
no auto-summary 

! 

router rip 

redistribute eigrp 2001 
passive-interface Ethernet0/1 
network 128.200.0.0 
default-metric 2 


At this point, the network is close to being complete. However, if you observe the routing 
table on storm, you see that it does not have a route to 128.200.3.16/29, as illustrated in 


Figure 9-4. 


Figure 9-4. Route Table Discrepancies: RI P/ E1GRP Network Before 
Summarization 
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Because the Ethernet segment between rogue and cyclops is on a 29-bit boundary, and 
because the segment between rogue and wolverine is on a 24-bit boundary, the rogue router 
will not forward any 29-bit network updates out its EO/O port. Performing a debug ip rip 
command on the rogue router as done in Example 9-10 substantiates this. 


Example 9-10 debug ip rip Command Output from rogue 


rogue#debug ip rip 
RIP protocol debugging is on 


te 


RIP: received vl update from 128.200.1.1 on Ethernet0/0 
128.200.10.0 in 1 hops 
128.200.2.0 in 1 hops 
RIP: sending vl update to 255.255.255.255 via Ethernet0/0O (128.200.1.2) - 
suppressing null update 
RIP: received vl update from 128.200.1.1 on Ethernet0/0 
123.200.10.0 in 1 hops 
128:2200.2:.0° an 1, Hops 
rogue# 


To allow full IP reachability between cyclops and storm, the route between them must be 
summarized on a 24-bit boundary. To accomplish this, use the following command on the 
cyclops router: 


cyclops (config-if)#ip summary-—address eigrp 2001 128.200.3.0 255.255.255.0 


Observing the routing table on rogue, as in Figure 9-5, an EIGRP route 128.200.3.0/24 now 
exists. Because the route has a 24-bit mask, rogue can forward it out its EO/0O port, where 
storm will eventually receive the route. 


Figure 9-5. Route Table Discrepancies Resolved: RIP/ EIGRP Network 
After Summarization 
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CAUTION 


Caution should be used whenever redistributing one routing protocol into 
another. Potential routing loops can occur if there are two or more redistribution 
points within the network. When multiple redistribution points are in the 
network, distance vector protocols are vulnerable to loops. Use the route maps 
with a well-thought-out IP addressing scheme to control loops. 


TIP 


Whenever you are working with routing protocols that don't carry a subnet mask 
within the routing update, such as RIP-1 and |GRP, be extremely careful to 
preserve a consistent bit mask throughout the entire internetwork. For example, 
a RIP domain might be operating on 24-bit boundary, whereas an OSPF domain 
might have some LAN networks at the 24-bit boundary, but its entire WAN is 
using a 30-bit boundary. The RIP domain will have no problem reaching the 
LANs because of the bit boundary match; however, it will not be capable of 
reaching the WAN interfaces. To allow full reachability between the two domains, 
the OSPF WAN networks that reside on a 30-bit boundary must be summarized 
to a 24-bit boundary before redistribution into RIP. 
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RIP Default Routing 


A default route is necessary whenever connecting the Internet. Without it, the router would 
need a path to every single network in its routing table. A default route is configured to point 
to a gateway of last resort. When a router cannot find a specific match in its route table for a 
packet, it forwards that packet to the gateway of last resort. Cisco routers always perform 
classful route lookups, which means that they will not forward packets to a gateway of last 
resort unless the global ip classless command is set. The ip classless command is enabled 
by default in Cisco 1|OS Software Release 11.3 and later. 


The concept of default routing varies by each routing protocol. Each routing protocol uses a 
specific method when defining and advertising a default route. 


There are two steps to perform when configuring default routing with RIP: 


Step 1. Define or flag a default network. There are two ways to accomplish this. First, 
RIP will recognize the address of 0.0.0.0 as a default route. Default routes like this 
are created by adding a static route of all Os, as in ip route 0.0.0.0 0.0.0.0 a.b.c.d, 
to the router. When this static route is created, it is not necessary to redistribute it 
into RIP. It will be propagated automatically by RIP. The second way to flag a route as 
a default is through the ip default-network a.b.c.d command. 


Step 2. Ensure that ip classless is enabled on the router. Without ip classless, 
routers will not forward traffic to the gateway of last resort. 


In Figure 9-6, the dr_xavier router was added to the network from the previous examples. 
This router has a default route to the Internet, through Internet_router/Firewall. This 
example uses a default static route to mark the route as the default. Adding the ip route 
0.0.0.0 0.0.0.0 206.191.240.2 command to the dr_ xavier router propagates a default 
route to rogue and cyclops. The route table for the dr_ xavier router marks this route with an 
*, meaning that the route is the candidate default. When the route is propagated to a 
downstream router, it becomes a gateway of last resort, as shown in Figure 9-6. 


Figure 9-6. RIP Default Routing 
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Example 9-11 lists the configuration of the dr_ xavier router. 


Example 9-11 Relevant Portions of the dr_ xavier Configuration 


! 

router rip 

network 128.200.0.0 
network 206.191.240.0 
! 

ip classless 


ip route 0.0.0.0 0.0.0.0 206.191.240.2 
! 
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Lab 20: Integrating RIP Networks: Redistribution, Route Filtering, and 
Control—Part | 


Practical Scenario 


RIP is still one of the most common routing protocols in use today. Although it might not be the 
dominant protocol on most major internetworks, RIP domains remain sprinkled throughout the 
internetwork. Integrating these domains and compensating for RIP's lack of support for VLSM can 
be challenging. This lab gives you practice in integrating RIP and controlling routing updates. 


Lab Exercise 


Habano Net runs distribution and export information for some of the finest cigar manufactures in 
the world. Information in Habano Net flows from cigar makers, such as montecristo and 
romeo_y_julieta to habanos. From here, habanos has connections to worldwide importers, such 
as churchill. imports. The task will be to integrate the RIP network of the cigar makers to the 
EIGRP networks of the exporters. Use the following parameters as your design guidelines: 


e Use the IP subnet 150.100.100.0/24 for the Frame Relay network between the habanos, 
montecristo, and romeo_y_julieta routers. Use RIP as the routing protocol. Ensure that 
montecristo has IP connectivity to romeo_y_julieta. 

e Use the IP subnet of 150.100.200.0/30 for the Frame Relay link between the habanos and 
churchill_ imports router. Use EIGRP with 2001 as the autonomous system for the routing 
protocol. 

e Mutually redistribute RIP into EIGRP on the habanos router. Ensure full |P reachability 
across the entire network. 

e Prevent the subnet 150.100.10.0/24 on the habanos router from reaching montecristo and 
romeo_y_julieta. 

e (Optional) Configure the habanos router so that all routes from romeo_y_julieta have an 
administrative distance of 5. 


Lab Objectives 


e Configure Habano Net as depicted in Figure 9-7, and configure IP as denoted as well. The 
LAN topology type is not important in this lab. 


Figure 9-7. Habano Net 
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e Use Frame Relay as the data-link protocol on the WAN. 

e Configure RIP and EIGRP as shown in Figure 9-7. Redistribute between RIP and EIGRP to 
provide full IP connectivity across the network. Prevent excess routing protocol broadcasts 
from entering segments that are not running that protocol. 

e Prevent the subnet 150.100.10.0/24 on the habanos router from reaching montecristo and 
romeo_y_julieta. 

e (Optional) Adjust the administrative distance of routes originating from romeo_y_julieta. 


Equipment Needed 


e Five Cisco routers, connected through V.35 back-to-back cable or in a similar fashion. One 
router will serve as a frame switch and require four serial ports. 
e Four LAN segments, provided through hubs or switches. 


Physical Layout and Prestaging 


e Configure a Frame Relay switch to provide the PVCs as listed in Figure 9-7. See Chapter 1, 


"The Key Components for Modeling an Internetwork," if you need assistance in configuring 
a Frame Relay switch. Example 9-12 provides a sample Frame Relay switch configuration. 


e Connect the hubs and serial cables to the routers as shown in Figure 9-7. 


Example 9-12 Frame Relay Switch Configuration 


hostname frame_switch 
! 
frame-relay switching 
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! 

interface Serial0 

no ip address 

encapsulation frame-relay 

no fair-queue 

clockrate 148000 

frame-relay intf-type dce 
frame-relay route 121 interface 
! 

interface Seriall 

no ip address 

encapsulation frame-relay 
clockrate 148000 

frame-relay intf-type dce 
frame-relay route 110 interface 
frame-relay route 120 interface 
frame-relay route 130 interface 
! 
interface Serial3 

no ip address 

encapsulation frame-relay 
clockrate 64000 

frame-relay intf-type dce 
frame-relay route 131 interface 
! 
interface Serial5 

no ip address 

encapsulation frame-relay 
clockrate 64000 

frame-relay intf-type dce 
frame-relay route 111 interface 


Seriall 


Serial5 
SerialO 
Serial3 


Seriall 


Seriall 


120 


111 
121 
131 


130 


110 
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Lab 20: Integrating RIP Networks: Redistribution, Route Filtering, 
and Control—Part Il 


Lab Walkthrough 


Attach the four routers in a back-to-back manner to the Frame Relay switch. Use V.35 cables or 
CSU/DSUs with crossover cables to connect the routers to the Frame Relay switch. Create the 
four LANs by the use of switches or hubs/MAUs. 


When the physical connections are complete, assign IP addresses to all LAN interfaces, as 
depicted in Figure 9-7. Be sure that you can ping the router's local LAN interface before moving 
on. 


First, we will focus on configuring the routers in the RIP domain. Start by configuring a 
multipoint subinterface on the habanos router. The network between habanos, montecristo, and 
romeo_y_julieta is a multipoint network, so you need to use frame-relay map statements. 
Example 9-13 shows this portion of the Frame Relay configuration. 


Example 9-13 Frame Relay Configuration Part 1—RIP 


! hostname habanos 

! 

interface Serial0O.1 multipoint 

ip address 150.100.100.1 255.255.255.0 

no arp frame-relay 

frame-relay map ip 150.100.100.2 110 broadcast 
frame-relay map ip 150.100.100.3 120 broadcast 
no frame-relay inverse-arp 


hostname montecristo 

! 

interface Serial0d 

ip address 150.100.100.2 255.255.255.0 

no ip directed—-broadcast 

encapsulation frame-relay 

no ip mroute-cache 

frame-relay map ip 150.100.100.1 111 broadcast 
frame-relay map ip 150.100.100.3 111 broadcast 
frame-relay lmi-type cisco 


hostname romeo_y_julieta 

! 

interface Serial0d 

ip address 150.100.100.3 255.255.255.0 

no ip directed—-broadcast 

encapsulation frame-relay 

no ip mroute-cache 

frame-relay map ip 150.100.100.1 121 broadcast 
frame-relay map ip 150.100.100.2 121 broadcast 
frame-relay lmi-type cisco 
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At this point, you should be able to ping the WAN interfaces that you configured. 


To configure RIP, use the router rip and the network 150.100.0.0 commands on each router 
in the RIP domain. Because the Frame Relay network is a multipoint network, you need to 
disable split horizons on the habanos router. Without disabling split horizons, the montecristo 
Token Ring network will not propagate to the romeo_y_julieta router. The opposite also is true. 
To disable split -horizons, use the no ip split-horizon command on the Serial0.1 interface on 
the habanos router. 


Now that the RIP domain is complete, let's begin to configure the EIGRP domain. The first step is 
to configure a Frame Relay point-to-point network between the habanos and churchill_ imports 
router. Example 9-14 shows the configuration, which uses Frame Relay inverse ARP. 


Example 9-14 Frame Relay Configuration Part 2—EI GRP 


! hostname habanos 

! 

interface Serial0.2 point-to-point 
ip address 150.100.200.1 255.255.255.252 
frame-relay interface-dlci 130 

! 


! 
hostname churchill_imports 

! 

interface Serial0d 

ip address 150.100.200.2 255.255.255.252 
encapsulation frame-relay 

no fair-—queue 


frame-relay interface-dlci 131 
! 


The EIGRP configuration is almost identical to the RIP configuration. Use the router eigrp 2001 
command along with the network 150.100.0.0 statement on the habanos and 
churchill_ imports routers. If you need more assistance in configuring EIGRP, see Chapter 11, 


"Hybrid: Enhanced Interior Gateway Routing Protocol (EIGRP)." 


To have full |P connectivity, you need to mutually redistribute between RIP and EIGRP on the 
habanos router. To accomplish this, use the redistribute command along with a default metric. 
The default metric for RIP is 2, and the default metric for EIGRP is 10000 1000 254 1 1500. Use 
the passive-interface command to avoid sending both RIP and EIGRP route updates out the 
same interface. Example 9-15 shows the updated configuration on habanos. 


Example 9-15 Routing Protocol Configuration on habanos 


! hostname habanos 
! 


router eigrp 2001 
Pi tacks hes a *“~ Redistributing RIP 
*— prevents EIGRP broadcasts 
passive-interface Serial0O.1 
network 150.100.0.0 


default-metric 10000 1000 254 1 1500 
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router rip 


“redistribute eigrp 2001 *~ Redistributing EIGRP 


prevents RIP broadcasts 
network 150.100.0.0 
default-metric 2 
! 


You now should have a full routing table on the churhcill_ imports router. You can see two EIGRP 
routes, 150.100.100.0/24 and 150.100.10.0/24 because the EIGRP distance is lower then that of 
RIP. You can also see two external EIGRP routes, 150.100.2.0/24 and 150.100.1.0/24, which 
come from RIP being redistributed into E1GRP. Example 9-16 shows the updated routing table 


for the churchill_ imports router. 


Example 9-16 Routing Table of churchill_ imports 


churchill_imports#show ip route 
<<<text omitted>>> 
150.100.0.0/16 is variably subnetted, 6 subnets, 2 masks 


Cc 150.100.200.0/30 is directly connected, Serial0 

D 150.100.100.0/24 [90/2681856] via 150.100.200.1, 00:29:52, Serial0d 
D EX 150.100.2.0/24 [170/2425856] via 150.100.200.1, 00:18:01, Serial0d 
iC 150.100.3.0/24 is directly connected, Ethernet0 

D EX 150.100.1.0/24 [170/2425856] via 150.100.200.1, 00:18:01, Serial0d 
D 


150.100.10.0/24 [90/2195456] via 150.100.200.1, 00:29:52, Serial0d 
churchill_imports# 


The configuration is almost complete; however, if you observe the routing table on montecristo 
in Example 9-17, you see that the 150.100.200.0/30 route is missing from the table. 


Example 9-17 Routing Table of montecristo 


montecristo#show ip route 

<<<text omitted>>> 

150.100.0.0/24 is subnetted, 5 subnets 
150.100.100.0 is directly connected, Serial0O 
150.100.2.0 [120/2] via 150.100.100,1, 00:00705, Seriald 
150,100.30 [120/72] vie 150.100:.100.1,. 00300305, Serialo 
150.100.1.0 is directly connected, TokenRing0O 
150.100.,10.20 [120/11]. via 150.100.100.171, 00200305, Serialo 

montecristo# 


HAaADWOA 


The 150.100.200.0/30 route is missing from the table because the bit mask is on a 30-bit 
boundary, and RIP does not forward the update out the Serial0.1 port of the habanos router. To 
remedy this, you need to summarize EIGRP on a 24-bit boundary on the Frame Relay link 
between habanos and the churchill_ imports routers. To summarize the route, use the ip 
summary-address eigrp 2001 150.100.200.0 255.255.255.0 command on the Serial 0 
interface of the churchill_ imports router. You now can observe the routing table on montecristo 
and see that it has a summary route to 150.100.200.0/24, as demonstrated in Example 9-18. 


Example 9-18 Complete Routing Table on montecristo 


montecristo#show ip route 
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<<<text omitted>>> 
150.100.0.0/24 is subnetted, 6 subnets 


150.100.100.0 is directly connected, Serial0O 

150.100.2..0 [120/2] via 150.100.100.1, O0700:02, Serialo 
150.100.3.0 [120/2] via 150.100.100.1, 00:00:02, Serial0O 
150.100.1.0 is directly connected, TokenRing0O 
150.100.10.0 [120/1] via 150.100.100.1, 00:00:02, Serial0O 
montecristo# 


AaADWDOA 


TIP 


When you are modeling complex networks, it might take a while for network 
convergence and routes to propagate. You can force a route update to speed this 
process along by using the clear ip route * command. This flushes all routes and 
force routing updates to happen. 


When you have full IP connectivity, you can start to filter routes. In this model, you want 
prevent the route 150.100.10.0/24 from being propagated to the montecristo and 
romeo_y_julieta routers. To accomplish this, use a distribute-list out under the RIP portion of 
the habanos router. You also need to define an access list filtering out the network 
150.100.10.0. Example 9-19 shows the final configurations. 


Example 9-19 Complete Routing Listings 


' 

interface Ethernet2 

ip address 150.100.10.1 255.255.255.0 
media-type 10BaseT 

interface Serial0d 

no ip address 

encapsulation frame-relay 

no ip mroute-cache 

! 

interface Serial0O.1 multipoint 

ip address 150.100.100.1 255.255.255.0 
no ip split-—horizon 

no arp frame-relay 

frame-relay map ip 150.100.100.2 110 broadcast 
frame-relay map ip 150.100.100.3 120 broadcast 
no frame-relay inverse-arp 

! 
interface Serial0.2 point-to-point 

ip address 150.100.200.1 255.255.255.252 
frame-relay interface-dlci 130 

! 
router eigrp 2001 

redistribute rip 

passive-interface Ethernet2 
passive-interface Serial0O.1 

network 150.100.0.0 


default-metric 10000 1000 254 1 1500 
! 
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router rip 

redistribute eigrp 2001 
passive-interface Serial0.2 
network 150.100.0.0 
default-metric 2 

distribute-list 10 out SerialOdO.1 
! 


ip classless 
! 


access-list 10 deny 150.100.10.0 0.0.0.255 


access-list 10 permit any 


ip subnet-—zero 
! 


interface Serial0 


ip address 150.100.100.2 255.255.255. 


no ip directed—-broadcast 
encapsulation frame-relay 

no ip mroute-cache 

frame-relay map ip 150.100.100.1 111 
frame-relay map ip 150.100.100.3 111 
frame-relay lmi-type cisco 

! 
interface TokenRingO 

ip address 150.100.1.1 255.255.255.0 
no ip directed-broadcast 

ring-speed 16 

! 
router rip 

network 150.100.0.0 

! 


ip classless 


broadcast 
broadcast 


! 

ip subnet-zero 

! 

interface Ethernet0O 

ip address 150.100.2.1 255.255.255.0 
no ip directed—-broadcast 

! 

interface Serial0d 


ip address 150.100.100.3 255.255.255. 


no ip directed-broadcast 
encapsulation frame-relay 

no ip mroute-cache 

frame-relay map ip 150.100.100.1 121 
frame-relay map ip 150.100.100.2 121 
frame-relay lmi-type cisco 

! 
router rip 

network 150.100.0.0 


broadcast 
broadcast 
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! 
interface Ethernet0O 

ip address 150.100.3.1 255.255.255.0 

! 
interface Serial0O 

ip address 150.100.200.2 255.255.255.252 
ip summary-address eigrp 2001 150.100.200.0 255.255.255.0 
encapsulation frame-relay 

no fair-—queue 

frame-relay interface-dlci 131 

! 

router eigrp 2001 


network 150.100.0.0 
! 


Finally, the optional portion of the lab specifies that you need to configure the administrative 
distance of all routes from romeo_y_julieta to be set to 5. To produce this result, use the 
distance command under RIP. In this model, you don't want to set the entire distance of RIP to 
5, but you want to set just the distance of routes from one neighbor. Therefore, you need to call 
an access list on the distance command as well, as demonstrated in Example 9-20. 


Example 9-20 Setting the Distance for Specific Routes 


! 
router rip 

redistribute eigrp 2001 
passive-interface Serial0O.2 
network 150.100.0.0 
default-metric 2 

distribute-list 10 out SerialO.1 


distance 5 150.100.100.3 0.0.0.0 11  *~ Set. distance for routes in list 11 only 
! 

ip classless 

! 


access-list 10 deny 150.100.10.0 0.0.0.255 
access-list 10 permit any 


access-list 11 permit 150.100.2.0 0.0.0.255 | *~ Allow only 150.200.2.0 through 
! 


Finally, viewing the route table on the habanos router in Example 9-21 shows that the route 
150.100.2.0 has an administrative distance of 5, versus the default distance of 120. 


Example 9-21 Setting the Distance for Specific Routes 


habanos#show ip route 
Codes: C — connected, S — static, I - IGRP, R —- RIP, M — mobile, B —- BGP 
D — EIGRP, EX — EIGRP external, O - OSPF, IA — OSPF inter area 
Nl - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 — IS-IS level-2, * - candidate default 
U -— per-user static route, o — ODR 


Gateway of last resort is not set 
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150.100.0.0/16 is variably subnetted, 7 subnets, 2 masks 


D 150.100.200.0/24 [90/2681856] via 150.100.200.2, 00:04:42, Serial0.2 
Cc 150.100.200.0/30 is directly connected, Serial0.2 

Cc 150.100.100.0/24 is directly connected, Serial0.1 

D 150.100.3.0/24 [90/2195456] via 150.100.200.2, 00:04:42, Serial0d.2 

R 150.100.1.0/24 [120/1] via 150.100.100.2, 00:00:07, Serial0O.1 

Cc 150.100.10.0/24 is directly connected, Ethernet2 

habanos# 
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Chapter 10. Distance Vector Protocols: Interior 
Gateway Routing Protocol (IGRP) 


When Cisco Systems developed the Interior Gateway Routing Protocol (IGRP) around 1986, 
network administrators didn't have many options to deal with some of RIP's limitations. RIP's 
hop-count limit of 15 and its simplistic metrics weren't allowing networks to scale and 
distribute traffic across paths of unequal cost. OSPF would not come out for another two 
years, and another routing protocol was needed. As the pioneer of internetworking, Cisco 
developed IGRP to specifically address some of RIP's shortcomings. 


IGRP has features that differentiate it from other distance vectors protocols: 


e Scalability— A hop count limit of 255 provides a broader network diameter versus 
RIP's hop-count limit of 15. The default hop for |GRP is 100. 


e Faster convergence— |IGRP uses Flash updates, which are updates that are sent to 
neighboring routers when topology changes occur. 


e Sophisticated metric— |GRP uses a composite metric based on five individual 
metrics—bandwidth, delay, reliability, load, and MTU—to influence routing decisions. 


e Unequal-cost load balancing— |GRP composite routing metrics allow for load 
balancing across multiple unequal-cost paths. 


These features provided significant enhancements over the routing protocols of the mid- 
1980s. But eventually, like RIP, |GRP networks will give way to their stronger brethren, 
Enhanced IGRP. This chapter covers the features and operation of I|GRP, along with 
configuration and redistribution of IGRP. 


638 


Technical Overview of IGRP 


IGRP is cast as a classful distance vector protocol that interfaces directly with the IP layer as 
protocol Type 9. It uses the concept of autonomous systems, where it periodically broadcasts 
its entire routing table to all of its neighbors. |GRP deploys several timers and metrics to 
control route validity. |GRP uses these mechanisms in the following manner: 


e Routing updates— Upon initialization, and every 90 seconds after that, |GRP 
broadcasts a routing update out all |GRP interfaces. This update includes all routes, as 
well as the route type and metric. This update includes every route in the route table, 
except routes suppressed by split horizon and filters. |GRP also uses Flash updates. 
Whenever network topology changes, |GRP sends out a Flash update to all its 
neighbors. The Flash update contains the entire route table. 


e Timers— A 90-second timer called the update timer triggers the sending of another 
routing update when the 90 seconds expires. When a route is learned from a 
neighbor, an invalid timer for the route is set to three times the update timer, or 270 
seconds. A flush timer is also set at this time; the default value of the flush timer is 
seven times the update timer, or 630 seconds. All the timers are defined as follows: 


- Update timer— This timer dictates how long a router waits between sending 
route advertisements. All route advertisements are offset by a random jitter to 
prevent synchronization problems. 


- Invalid timer— This timer dictates how long a router continues to advertise 
a route until it receives another update. When the invalid timer expires before 
an update, the route is marked as unreachable. 


- Flush timer— This timer dictates how long a router holds and advertises the 
route as unreachable before removing it from the routing table. 


- Hold-down timer— When a route becomes unreachable, or if the next-hop 
router increases the metric of the route, it is placed in holddown. The hold- 
down timer is three times the update timer plus 10 seconds; the default value 
is 280 seconds. Hold-down timers also prevent the router from receiving new 
information during convergence periods. 


The default timers can be changed with the timers basic update invalid holddown flush 
[sleeptime] command. The sleeptime parameter instructs the router to wait a specified period 
of time before sending a routing update after receiving a triggered update. 


IGRP deploys the concepts of split horizon and poison reverse to prevent 
routing loops. These concepts are described as follows: 


Split horizon— |GRP uses split horizon to prevent routing loops. Recall 
from earlier chapters that split horizon is the rule that information 
about a route is not be sent out the same interface or subinterface 
from which the route was received. By default, split horizon is enabled 
on all interfaces. This can be disabled with the no ip split-horizon 
interface command. 


Poison reverse— The router sends a poison reverse update to remove 
a route and place it in holddown. This is done to avoid a routing loop. A 
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split horizon update is sent when a router detects a metric increase of 
1.1 or greater. |GRP does this by setting the composite metric to 
4,294,967,295 and advertising the route back to the source. 


IGRP Route Types 


As you can see, the operation of the IGRP timers is similar to that of RIP's timers. One way in 
which the two routing protocols differ is in the way they advertise routes. The three major 
categories of |GRP routes follow: 


e Exterior route— An exterior route is a route flagged by the ip default-network a.b. 
c.d command. If the router has the ip classless command and |GRP has a default 
network configured, the router forwards any packets to the default network that it 
does not have a specific route to. 


e Interior or subnet route— A route is advertised as an interior route if the route is 
part of the major subnet class of the interface sending the route. 


e System or network route— A route is advertised as a system route if the route is 
not part of the major subnet class of the interface sending the route. System routes 
always are advertised as a Summary route on the major class boundary. 


Figure 10-1 illustrates the router advertising all three types of routes. In this example, the 


router highlighted has the ip default-network 206.191.241.0 command set in its 
configuration. This command flags the 206.191.241.0 route as an exterior route when 
advertising it. 


Figure 10-1. 1|GRP Routing Updates 
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In this example, igrp_rtr has four interfaces in the same autonomous system. The Ethernet 5 
(E5) interface is in subnet 172.16.1.0/24. Therefore, |GRP advertises the 172.16.2.0 route as 
a subnet route out the E5 interface. This is because the interface sending the route is inthe 


same major class boundary as the route itself. |GRP advertises the 172.18.1.0/24 route as a 
summary route of 172.18.0.0 out the E5 interface. This is because the sending interface is in 
a different major class boundary. Finally, |GRP advertises the 206.191.241.40/29 route as 
the exterior route 206.191.241.0. The receiving IGRP router treats this route as its default 
route, or gateway of last resort. 


IGRP Metric Types 


Another significant enhancement that |GRP provides over RIP is the use of complex 
composite metrics. Bandwidth, delay, load, reliability, and MTU are the submetrics. By 
default, |GRP chooses a route based primarily on bandwidth and delay. For a complete 
explanation on how the composite metric is derived and influenced by setting k values, see 
Chapter 11, "Hybrid: Enhanced Interior Gateway Routing Protocol (EIGRP)." The following list 
provides a more detailed description of the five |GRP metrics: 


e Bandwidth— Bandwidth is expressed in units of kilobits. lt must be statically 
configured to accurately represent the interfaces that IGRP is running on. For 
example, the default bandwidth of a 56-kbps interface and a T1 interface is 1544. To 
accurately adjust the bandwidth, use the bandwidth kbps interface subcommand. 
Table 10-1 highlights some common bandwidth settings. 


e Delay— Delay is expressed in microseconds. It, too, must be statically configured to 
accurately represent the interface that |GRP is running on. The delay on an interface 
can be adjusted with the delay time_in_microseconds interface subcommand. 


e Reliability— Reliability is a dynamic number expressed as a value from 1 to 255. 
Here, 255 represents a 100 percent reliable link, whereas 1 represents an unreliable 
link. 


e Load— Load is a number in the range of 1 to 255 that shows the output load of an 
interface. This value is dynamic and can be viewed by the show interfaces 
command. Here, 1 represents a minimally loaded link, whereas 255 represents a 100 
percent loaded link. 


e MTU— This is the smallest maximum transmission unit (MTU) value in the path. 
NOTE 


Whenever you are influencing routing decisions in |GRP or EIGRP, use the metric 
of delay over bandwidth. Changing bandwidth can affect other routing protocols, 
such as OSPF. Changing delay affects only |GRP and EIGRP. 


Table 10-1 highlights the common metrics used. 


Table 10-1. Common IGRP and EI GRP Metrics 


| Medium Bandwidth | Delay | 
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100M ATM 100,000 kbps 100 microseconds 
Fast Ethernet 100,000 kbps be microseconds 
FDDI 100,000 kbps 100 microseconds 
45,045 kbps 20,000 microseconds 
16M Token Ring 16,000 kbps 630 microseconds 
10M Ethernet (10,000 kbps 1000 microseconds 
T1 1544 kbps 20,000 microseconds 
DS-0O 64 kbps 20,000 microseconds 


56K [56 kbps 20,000 microseconds 


* These metrics are not the actual metrics that get communicated in the 
IGRP updates. These metrics are used to derive the composite metric that 
actually is sent in the update. 
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Configuring IGRP 


Configuring basic |GRP is a two-step process. Configuring |GRP calls for the definition of an 
autonomous system (AS). By definition, an autonomous system is a set of routers under a 
single administrative technical authority. |GRP, EIGRP, and BGP all use the concept of 
autonomous systems, but BGP is the only routing protocol that actually utilizes the AS in 
routing decisions. It is not required to have a registered AS when configuring |GRP or EIGRP. 


This following two-step process can be followed by an optional third step to fine-tune |GRP to 
specific environments: 


Step 1. Enable I|GRP and define an autonomous system on the router. This is 
accomplished with the router igrp autonomous_system_id global command. 


Step 2. Add the networks that you want to run |GRP on. This is accomplished with the 
network a.b.c.d command from the config-router# mode. When you enter the 
network statements, it is necessary to enter only the major class boundary. 


Step 3. Optional: Fine-tune |GRP metrics with bandwidth statements, or configure 
IGRP timers and options. 


Example 10-1 illustrates the IGRP configuration from Figure 10-1. 


Example 10-1 1GRP Configuration 


! hostname igrp_rtr 

! 

router igrp 2001 =“ IGRP routing process 
“network 172.16.0.0 "Networks running IGRP 


network 206.191.241.0 
! 


ip classless 


ip default-network 206.191.241.0 *~Default Network 
! 


Before moving on to configuring other |GRP options, let's take a look at the "Big D" and the 
"Big show" commands for IGRP. 


The "Big show" and "Big D" for IGRP 


Troubleshooting IGRP is similar to troubleshooting RIP. Most of the configuration errors 
around |IGRP involve a bad network statement, discontinuous subnets, or inconsistent bit 
masks across the IGRP domain. The following is list of what | find to be the most useful show 
and debug commands for | GRP. 


e show ip protocols [summary] 
e Router#show ip route 
e Router(config-router)#debug ip igrp [transactions | events] 
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The sections that follow explain these commands in greater detail. 
show ip protocols [summary] Command 


This command displays all routing protocols, detailed timer and metric information, as well as 
routing update information. Example 10-2 lists the output of the show ip protocols 
command. 


Example 10-2 Output of the show ip protocols Command 


igrp_rtr#show ip protocols 


(ESSss Se eUEE Sr Sere very rt reeecne sete ae essa «= Peeters 
_ Invalid after 270 seconds, hold down 280, flushed after 630 *~ Other 3 timers 
Outgoing update filter list for all interfaces is 
Incoming update filter list for all interfaces is 
Default networks flagged in outgoing updates 
Default networks accepted from incoming updates 
“Metrics 
IGRP maximum hopcount 100 
IGRP maximum metric variance 1 
Redistributing: igrp 2001 
‘Networks IGRP is routing for 
V72.16.0.0 
LI2.18..0'..0 
2062191..241..0 
— 
Gateway Distance Last Update 
VIA 61821455 100 OO OCs 29 
206.191.241.42 100 00:00:06 
i eos ee 100 00:01:06 
V7 26166204 100 00:38:38 
L726, Gi Ud 100 005.0 3:01 
_ Distance: (default is 100) "Administrative Distance 


igrp_rtr# 
show ip route Command 


This command lists the router's current routing table and the one that it uses to make 
forwarding decisions. The output lists what routing protocol the route is from—in this case, I 
for |GRP. The number behind the route is the administrative distance of the route followed by 
the composite metric of |GRP. The via field explains who the route is from, how long ago an 
update was received, and by what interface it was received. Example 10-3 lists the output of 
the show ip route command. In this example, the route 206.191.241.0/24 is the default 
route, marked by the *. It has an administrative distance of 100 and a composite metric of 
1200. The IGRP neighbor informing the router about the route is 172.18.1.5. The last update 
about the route occurred 52 seconds ago, through the Ethernet 0 port. 
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Example 10-3 show ip route Command Output 


r/7#show ip route 
Codes: C -— connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 
D — EIGRP, EX —- EIGRP external, O - OSPF, IA —- OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U -— per-user static route, o — ODR 


Gateway of last resort is 172.18.1.5 to network 206.191.241.0 


T 172.16.0<.0/16: [1000/1200] via 172.18.1.5, 00:00:53, Hthernet0 
172.18.0.0/24 is subnetted, 3 subnets 

i 172.18.18.0 [2100/1600] via 172.18.1.55, 00:00:29, Ethernet0 

Cc 172.18.19.0 is directly connected, Loopback20 

Cc 172.18.1.0 is directly connected, Ethernet0O 

cit 


Router(config-router)#debug ip igrp [transactions | events] Command 


The debug ip igrp transactions command shows detailed information about the routing 
updates being sent and received by the various interfaces. The debug ip igrp transactions 
command provides comprehensive routing detail, listing the networks and composite metric 
of each network. Both the commands show which interfaces are sending and receiving routes. 
The debug ip igrp events command provides only what type of routes are being advertised 
and received. Example 10-4 lists the output of the debug ip igrp transactions command, 
whereas Example 10-5 lists the output of debug ip igrp events. Use Figure 10-1 as 
reference for this output, which was performed on the igrp_ router. 


Example 10-4 debug ip igrp transactions Command Output 


01:40:07: IGRP: received update from 206.191.241.42 on Ethernet0O 


O12 402072 network 172.16.0.0, metric 1121211 (neighbor 1121111) 
01:40:27: IGRP: sending update to 255.255.255.255 via EthernetO (206.191.241.46) 
Oise AOe2 7s network 172.16.0.0, metric=1100 

OL 4Oe27 8 network 172.18.0.0, metric=1100 

01:40:27: IGRP: sending update to 255.255.255.255 via Ethernetl (172.18.1.5) 
Od 40s 278 network 172.16.0.0, metric=1100 

O1S A027 exterior 206.191.241.0, metric=1100 

01:40:27: IGRP: sending update to 255.255.255.255 via Ethernet3 (172.16.2.5) 
Ole Ar Ts subnet 172.16.1.0, metric=1100 

OL S402927% network 172.18.0.0, metric=1100 

Ola Oe2 78 exterior 206.191.241.0, metric=1100 

01:40:27: IGRP: sending update to 255.255.255.255 via Ethernet5 (172.16.1.5) 
Od. 4027s subnet 172.16.2.0, metric=1100 

OLs40227 network 172.18.0.0, metric=1100 

Ot 4Oe27 5 exterior 206.191.241.0, metric=1100 

igrp_rtr# 


Example 10-5 debug ip igrp events Command Output 


02:52:53: IGRP: sending update to 255.255.255.255 via EthernetO (206.191.241.46) 
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Update contains 
Total routes in 


OQ interior, 2 
update: 2 


sending update to 255.255.255. 


Update contains 
Total routes in 


OQ interior, 1 
update: 2 


sending update to 255.255.255. 


Update contains 
Total routes in 


1 interior, 1 
update: 3 


sending update to: 255.255.2595. 


Update contains 
Total routes in 
received update 
Update contains 
Total routes in 


1 interior, 1 
update: 3 
from 172.18 ..1. 
1 interior, 0 
update: 1 


system, and 0 exterior 


255 wise 
system, 


Ethernetl 
and 1 exterior 


255. Wile 
system, 


Ethernet3 
and 1 exterior 


255 via 
system, 


Ethernet5 (172 
and 1 exterior 


7 on Ethernetl 
system, and 0 exterior 


(LT2 


(LZ: 


routes. 


13.25) 
routes. 


64025) 
routes. 


AG. 135) 


routes. 


routes. 
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Tuning, Redistribution, and Controlling IGRP Updates 


Like RIP, |GRP has several parameters for tuning timers, controlling broadcasts, load-sharing, 
and controlling routes. The following is a list of parameters adjustable within |GRP: 


e Router(config-router)#timers basic update invalid holddown flush [sleeptime]— 
This allows the user to set the update, invalid, hold-down, flush, and optional sleep 
timers for IGRP. 


To allow IGRP unicast updates, define a next-hop neighbor with the neighbor 
command. The command functions identically to the RIP version. For more information 
on configuring unicast routing updates, see Chapter 9, "Distance Vector Protocols: 
Routing Information Protocol Versions 1 and 2 (RIP-1 and RIP-2)." 

e Router(config-router) #passive-interface interface _name— This command prevents 
routing updates from being sent on an interface. The router, however, still listens to 
broadcast or unicast updates as they are received on that interface. 


e Router(config-router)#neighbor a.b.c.d— This command defines an |GRP neighbor 
to exchange unicast updates with. This command should be used in conjunction with the 
passive-interface command. 


e Router(config-router) #offset-list [access list_0-99 [in | out] offset {metric_offset_ 
1-214748364} [interface]— Use this command to increase the value of the routing 
metrics. The metric offset cannot exceed 214,748,364. 


To filter routing updates in IGRP, use a distribute list. A distribute list, as you recall, 
calls a standard or extended access list and filters routing updates accordingly. When 
redistributing one protocol into another, use the redistribute command along with the 
default metric. A route map should be used in place of a distribute list when controlling 
specific routes during the redistribution process. In the section on |GRP integration, you 
can see an example of redistribute and default-metric commands. 

e Router(config-router)#distribute-list{1-199} [in | out] [interface]— Use this 
command to call a standard or extended access list to filter inbound or outbound routing 
updates. 


e Router(config-router)#redistribute {connected | static | bgp | rip | eigrp | ospf 
| isis} [metricmetric-value] [route-mapmap-tag]— Use this command to redistribute 
other routing protocols into |GRP. A route map can be added for additional route 
control. An optional metric also can be supplied for routes originating from the routing 
protocol being redistributed that are different from the default metric. Whenever 
redistributing routes, remember that IP needs a route to and from a destination. Many 
times mutual redistribution might be required to give IP a path to and from its 
destination. 


e Router(config-router)#default-metric bandwidth_kbps 1-4214748364 delay _ 
microseconds 1-4214748364 reliability 1-255 load 1-244 mtu 1-4214748364— Use this 
command to set the default metric of all routes redistributed into |GRP. Keep in mind 
that if the metrics are defined on the redistribute command shown previously, those 
metrics override any metrics set here. You must supply a default metric when 
redistributing between protocols either by using the default-metric command or by 
specifying the metrics on the redistribute command. A common metric to use is 
default-metric 10000 1000 254 1 1500. This metric tells the router to derive the 
composite metric from the values of bandwidth of 10000, a delay of 1000, a load of 1 
(or no load), and an MTU of 1500. The link is 254 reliable here, where 255 is 100 
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percent reliable. 


The following subsets of commands are used to influence routing decisions. Individual metrics 
can be modified, as can the administrative distance of the IGRP. Whenever influencing a 
specific links metric, use the delay command over the bandwidth command. Both can be 
used, but OSPF also is affected by bandwidth, whereas delay affects only |GRP and EIGRP. 


e Router(config-router)#metric weights 0 k1 k2 k3 k4 k5— This command enables 
you to set the weight of the |GRP metric in terms of bandwidth, load, delay, and 
reliability. 


e Router(config-router)#distance weight_1-255 [adjacent_neighbors ip address 
wildcard_mask [access_list_0-99]]— Use this command to change the administrative 
distance of routes received from a neighbor. If the |1P address and wildcard mask are 
omitted, all routes for that protocol are set to the distance value. For a specific example 
and more practice with the distance command, see Chapter 9 lab 20. 


e Router(config-if)#delay microseconds _1-4214748364— This command specifies the 
delay of an interface in tens of microseconds. This command is used only by routing 
protocols and does not affect traffic on the link. 


e Router(config-if)#bandwidth bandwidth_kbps_1-4214748364— This command 
specifies the bandwidth of an interface in kilobits per second. This command is used only 
by routing protocols and does not affect traffic on the link. 


Unequal-Cost Load Balancing 


IGRP has the capability to use unequal-cost load balancing. The router uses variance as a 
multiplier in choosing the upper boundary of path with the greatest metric. 


Configuring unequal-cost load balancing is a three-step process: 


Step 1. Configure the bandwidth on both sides of all the interfaces involved in the load- 
sharing group. Use the bandwidth kbps command to accomplish this. 


Step 2. Define the lowest-cost metric and the highest-cost metric. From these values, 
compute the variance multiplier and add it to the IGRP routing process. 


Step 3. Optional: Set the maximum-paths or the traffic-share variables. 


The following example walks through the calculation of a fictional variance. |GRP has a route, 
and the metric of that route is 100. The router also has two more routes to that same 
destination, and the metrics for those routes are 200 and 300. To allow |GRP to use all three 
paths in sharing data, you would set the variance to 3. (3 x 100) = 300, or (Best_ metric) x 
(variance) = Largest metric of path to load share over. To properly set the variance, use the 
following formula: 


Variance = | + ({(Metnc of highest-cost route) / (Metric of the lowest cost route)} 


Rounded up to the nearest 1s decimal place) 


The metric of the lowest-cost route can be discovered with the debug ip igrp transactions 
command. Be sure to change the variance and other variables on both ends of the mae 


bandwidth also should be set on all serial links. The following syntax is used in configuring load 
balancing: 


e Router(config-router)#variance metric_multiplier 1-128— Defines the metric 
multiplier of which routes to use in unequal-cost load balancing. The default variance is 
1, which is equal-cost load balancing. 


e Router(config-router)#maximum-paths 1-6— By default, the router uses four equal- 
cost paths for load sharing, but up to six paths can be set using this command. This 
command also can be used to limit this number. The multiple paths that make up a 
single-hop transport to a common destination are called a load-sharing group. 


e Router(config-router)#traffic-share {balanced | min}— If multiple minimum-cost 
paths exist and traffic-share min is configured, |GRP uses equal-cost load balancing. 
By default, the command is set to balanced, where traffic is distributed proportionally 
to the ratio of the metrics. For example, if the variance is set to 3 and traffic-share is 
set to balanced, the best route transports traffic three times that of the worst route. 


e Router(config-router)#bandwidth xx-kbps— This command configures bandwidth 
that IGRP uses in route decisions. 


For a route to be included in unequal-cost load sharing, three other conditions must be met: 


e The maximum paths limit must not be exceeded as a result of adding this route to the 
load-sharing group. 

e The downstream router must be metrically closer to the destination. 

e The metric of the lowest-cost route, multiplied by the variance, must be greater than 
the metric of the route to be added to the load-sharing group. 


Configuring IGRP Unequal-Cost Load Sharing 


In the network model in Figure 10-2, there are two routers: klipsch and carver. The routers are 
connected by two serial links: One link is running at 56 kbps, and the other is running at T1 
speeds. The routers are both running IGRP in the private autonomous system of 65,001. In this 
model, you want to enable unequal-cost load balancing across the serial links. 


Figure 10-2. IGRP with Unequal Metric Calculation 


Klipsch carver 
56 kbps: 


S1-1P-172. 16.10. 1/24 STIDCEMMP-172 1610424 or 


7  —_i"@9 
 SOP7246.011e4 §1(0CE-IP-172.16.11.44 
ESP 192.168.1124 | 154akbps SWOCEr | ECP 172. 16,1 104 


The first step, after configuring basic |GRP, is to set the bandwidth on the serial interfaces. |f 
IGRP is enabled without tuning the bandwidth, the routers get an inconsistent view of the 
metrics of the network. In Example 10-6, the klipsch router has calculated a composite metric 
of 180,671 for the subnet 172.16.1.0 from the Serial 1 interface. On the other hand, the router 
has calculated a metric of 8576 for the same route from the Serial O interface. 
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How IGRP calculates the metrics for each route can be displayed by the debug ip igrp 
transactions command, as shown in Example 10-6. 


Example 10-6 Metric of the 172.16.1.0 Route on klipsch 


klipsch# debug ip igrp transactions 
IGRP protocol debugging is on 


klipsch# 
00:50:05: IGRP: received update from 172.16.11.4 on SerialO 
OOF50205s subnet 172.16.10.0, metric 182571 (neighbor 180571) 


00:50:05: IGRP: received update from 172.16.10.4 on Seriall 


O10 50 205 subnet 172.16.11.0, metric 182571 (neighbor 8476) 
00s 50205: subnet 172.16.100.0, metric 182671 (neighbor 8576) 
klipsch# 


Example 10-7 illustrates how, without setting the bandwidth on both sides of the serial links, 
the routers might have different perspectives on the link. 


Example 10-7 Metric of 192.168.1.0 Route of carver 


carver#debug ip igrp transactions 

IGRP protocol debugging is on 

03:12:26: IGRP: received update from 172.16.11.1 on Seriall 
OS212 226% subnet 172.16.10.0, metric 10476 (neighbor 8476) 


03:12:26: IGRP: received update from 172.16.10.1 on Serial? 


OB 2 e263 network 192.168.1.0, metric 89056 (neighbor 1100) 


To assist in synchronizing the metrics, assign the bandwidth statement to the two serial 
interfaces. Once again, this is done with the bandwidth kbps interface command. After 
applying the bandwidth command, the metrics are consistent throughout the network, as 
shown in Example 10-8. 


Example 10-8 debug ip igrp transactions Command Output on the 
klipsch and carver Routers 


klipsch# 
03:54:18: IGRP: received update from 172.16.11.4 on SerialO 
OSE54 216i subnet 172.16.10.0, metric 182571 (neighbor 180571) 


03:54:19: IGRP: received update from 172.16.10.4 on Seriall 


OB: 54-2 19 subnet 172.16.11.0, metric 182571 (neighbor 8476) 
OSs54219s network 192.168.1.0, metric 182671 (neighbor 8576) 
carver# 

03:49:31: IGRP: received update from 172.16.11.1 on Seriall 

O24 92378 subnet 172.16.10.0, metric 182571 (neighbor 180571) 


03:49:31: IGRP: received update from 172.16.10.1 on Serial? 650 


OS'4923 1% subnet 172.16.11.0, metric 182571 (neighbor 8476) 


03:49:31: subnet 172.16.1.0, metric 182671 (neighbor 8576) 
carver# 
carver# 


The routing table is now consistent and all traffic flows through the lowest-cost path. Notice in 
Figure 10-3 that the routing table for the klipsch router now reports only the lowest-cost path 


to the network 172.16.1.0. 
Figure 10-3. 1GRP with Equal Metric Calculation 
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The final step is to set the variance. Recall that the formula to calculate variance is as follows: 


1+ ({highest_cost_path/lowest_cost_path] Rounded up) 


Therefore, in this example, you have 1 + (180671/8576) = 22. After the variance is set, the 
router reports two paths to the destination network and load-share over them. The load sharing 
is in an inverse proportion to the variance setting. In this model, every 22nd packet crosses the 
lowest-cost path. 


Finally, Example 10-9 lists the route table on the carver and klipsch routers when unequal-cost 
load balancing is in effect. Notice that all possible paths to the destination networks are listed. 


Example 10-9 show ip route Command Output Lists All Possible Paths 
to Remote Networks 


172.16.0.0/24 is subnetted, 3 subnets 


Cc 172.16.10.0 is directly connected, Serial7 
C 172.16.11.0 is directly connected, Seriall 
Cc 172.16.1.0 is directly connected, Ethernet0O 
carver# 


172.16.0.0/24 is subnetted, 3 subnets 
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Cc 172.16.10.0 is directly connected, Seriall 
172.16.11.0 is directly connected, Serial0O 


ie 192.168.1.0/24 is directly connected, Ethernet5 
klipsch# 


Qa 


Example 10-10 lists the configuration of the carver and klipsch routers. 


Example 10-10 Relevant Portions of the carver and klipsch Router 
Configurations 


hostname carver 

! 

interface Ethernet0O 

ip address 172.16.1.1 255.255.255.0 
! 

interface Seriall 

ip address 172.16.11.4 255.255.255.0 
bandwidth 1544 

clockrate 2000000 

! 

interface Serial7 

ip address 172.16.10.4 255.255.255.0 
bandwidth 56 

clockrate 56000 

! 
router igrp 65001 

variance 22 

network 172.16.0.0 

! 

ip classless 


hostname klipsch 

! 

interface Ethernet5 

ip address 192.168.1.1 255.255.255.0 
media-type 10BaseT 

! 

interface Serial0 

ip address 172.16.11.1 255.255.255.0 
no ip mroute-cache 

bandwidth 1544 

! 

interface Seriall 

ip address 172.16.10.1 255.255.255.0 
bandwidth 56 

! 

router igrp 65001 

variance 22 

network 172.16.0.0 

network 192.168.1.0 

! 

ip classless 
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IGRP and EIGRP Integration and Migration 


Migration from IGRP to EIGRP was designed to be an effortless migration. For the most part, 
this is true. If |GRP and EIGRP use the same Autonomous System IDs, redistribution occurs 
automatically. This facilitates a rather painless migration from IGRP to EIGRP. If the routing 
processes are in different autonomous systems, manual redistribution must be configured. 


IGRP is also a classful routing protocol, which means that routing updates in the same major 
class or bit boundary as the interface receiving the update must have a subnet mask that 
matches the mask of the interface receiving the update. If the update is in a different class, it 
automatically is summarized at that class's major bit boundary, 8-bit, 16-bit, or 24-bit. 
Therefore, care must be taken to use summarization so that all the networks are at the same 
bit boundary throughout the portion of the network that supports only classful routing. 


Expanding upon the model from the previous example, a new router has been added to the 
internetwork and some other subnet changes have been made, as illustrated in Figure 10-4. 


There now exists an EIGRP domain in the model. A router called dts is connected by a T1 serial 
link to the carver router. 


Figure 10-4. IGRP and EIGRP Integration 
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To integrate the dts router to the network, manual redistribution is necessary. This is because 
the network resides in different autonomous systems. Example 10-11 highlights the |GRP and 
EIGRP redistribution on the carver router. The passive-interface commands are not necessary 
but are configured to prevent unnecessary EIGRP hellos and IGRP broadcast from entering 
networks that they shouldn't. 


Example 10-11 1GRP and EIGRP Redistribution on the carver Router 


! 
router eigrp 2001 


“redistribute igrp 65001 © *~ Redistribute IGRP into EIGRP 
*~ do not send EIGRP hellos on these interfaces 
passive-interface Seriall 
network 172.16.0.0 


-default-metric 1544 100 254 1 1500 *~ Use this metric for redistributed routes 


no auto-summary 
! 


router igrp 65001 

“~Redistribute EIGRP into IGRP 
passive-interface Serial0O 
network 172.16.0.0 


_default-metric 1544 100 254 11500 "Default metric for redistributed routes 


The link between the carver and dts routers is on a 30-bit boundary. |GRP is not capable of 
advertising this network after it is redistributed because the subnet mask does not match the 
subnet mask on the advertising interface. To remedy this, summarize the 172.16.128.0/30 
network to 172.16.128.0/24 by using the ip summary-address eigrp 2001 172.16.128.0 
255.255.255.0 command under the Serial 0 interface of the carver router. 


Downstream routers, such as klipsch, now have IP reachability to the subnet 172.16.128.0/24. 
Example 10-12 lists the route table of the klipsch router. 


Example 10-12 Route Table of the klipsch Router 


klipsch#show ip route 
<<<text omitted>>> 
Gateway of last resort is not set 


172.16.0.0/24 is subnetted, 3 subnets 


i 172.16.128.0 [100/10476] via 172.16.11.4, 00:00:31, Serial0O 
Cc 172.16.11.0 is directly connected, Serial0O 

I 172.16.1.0 [1000/8576] via 172.16.11.4, 00:00:31, Serial0O 
klipsch# 


IGRP and Default Routing 


A default route is necessary whenever connecting to the Internet because, without it, the router 
would need a path to every single network in its routing table. Fundamentally, a default route 
points to a gateway of last resort. When a router cannot find a specific match in its route table 
for a packet, it forwards that packet to the gateway of last resort. Cisco routers always perform 
a classful route lookup, which means that they do not forward packets to a gateway of last 
resort unless the global ip classless command is set. ip classless is enabled by default in 
Cisco |OS Software Release 11.3 and later. 


The concept of default routing varies by each routing protocol. Each routing protocol uses a 
specific method when defining and advertising a default route. 


The two steps to perform when configuring default routing with |GRP follow: 


Step 1. Define a default network. |GRP does not recognize the address of 0.0.0.0 asa 
default route. Recall that the IGRP actually advertises a route as an external network. 
To "flag" or define a network as external, two things must happen. First, the route must 
be flagged by the ip default-network a.b.c.d command. Second, for the route to be 
advertised as external, the interface advertising the route must not be in the same 
major class boundary as the default network. 


Step 2. Ensure that IP classless is enabled on the router. 
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In Figure 10-5, igrp_rtr has a default network of 206.191.241.40/29. The ip default-network 
206.191.241.0 command has been added to the configuration. This causes the route to be 
flagged as a default and as an external network. The route table for the igrp_rtr router marks 
this route with an *, meaning that the route is the candidate default. When the route is 
propagated to a downstream router, it becomes a gateway of last resort, as shown in Figure 10- 
5: 


Figure 10-5. 1GRP Default Network 
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Example 10-13 lists the configuration of the igrp_rtr router. 


Example 10-13 Relevant Portions of the igrp_rtr Configuration 


router igrp 2001 
network 172.16.0.0 
network 206.191.241.0 
! 

ip classless 


ip default-network 206.191.241.0 
! 
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Lab 21: Default Routing, Filtering, and Unequal-Cost Load Sharing in 
IGRP Networks—Part | 


Practical Scenario 


Most I|GRP networks have evolved into EIGRP networks, but some still remain. When working with 
IGRP networks, it is key to be able to control routing updates and propagate default information. 


The following lab gives you practice in controlling routing updates, filtering, and default routing. 
Lab Exercise 


The Sea Shepherd Conservation Society (SSCS), or Sea Shepherd International, is a powerful 
group of environmentalists committed to defending a segment of the world's population that has 
no voice. The SSCS has an organized navy that goes by the code name Neptune. The navy has 
several ships that operate out of various ports across the globe and patrol ecological hot spots 
enforcing United Nations sanctions. The Neptune Navel Intelligence Network links the various 
departments of the navy to allow the SSCS quick access to important data. Your task is to 
configure an IGRP network by using the following parameters as design guidelines: 


e Configure an 1P network, as depicted in Figure 10-6, using IGRP as the routing protocol 
and 65,001 as the Autonomous System ID. 


Figure 10-6. Neptune Naval I ntelligence Network 
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e Configure a default network to 204.30.121.0/24 from the sea_shepherd router, and 
propagate it throughout the |GRP domain. 

e The ocean_warrior router has a private subnet of 172.16.128.0/24. Prevent only the 
mirage router from seeing this subnet. 

e Configure the ocean_warrior router to use all possible paths to the default network. 

e Optional: Configure |GRP so that broadcasts are less intensive on the LAN segment 
between the ocean_ warrior, sirenian, and mirage routers. 


Lab Objectives 


e Configure the Neptune Naval Intelligence Network as depicted in Figure 10-6. Configure IP 
as denoted in the diagram. The LAN topology type is not important in this lab. 

e Use HDLC as the data-link protocol on the WAN. 

e Configure a default network and propagate it throughout the |GRP domain. 

e Configure unequal-cost load balancing to the default network from the ocean_ warrior 
router. 

e Filter subnet 172.16.128.0/24 of the ocean_ warrior router from reaching the mirage 
router. You might need to configure multiple access lists to accomplish this. 

e Optional: Configure |GRP unicast updates on the LAN segment between the ocean_ warrior, 
sirenian, and mirage routers. 


Equipment Needed 


e Four Cisco routers. Three will be connected through V.35 back-to-back cables or in a 
similar manner. 

e Three LAN segments, provided through hubs or switches. 

e You might want to test the configuration by adding a workstation with the IP address of 
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204.30.121.31 on the subnet of the sea_shepherd router. 
Physical Layout and Prestaging 


e Connect the hubs and serial cables to the routers, as shown in Figure 10-6. 


e Optional: Configure an IP workstation with the address of 204.30.121.3 to test the 
network. 
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Lab 21: Default Routing, Filtering, and Unequal-Cost Load Sharing in 
IGRP Networks—Part Il 


Lab Walkthrough 


Attach the two routers in a back-to-back manner to the sea_shepherd router. Use V.35 cables or CSU/ 
DSUs with crossover cables to connect the routers. Create the three LANs by the use of switches or 
hubs/MAUs. The LAN segment 172.16.128.0/24 on ocean_warrior can be simulated with a loopback 
interface. 


When the physical connections are complete, assign IP addresses to all LAN and WAN interfaces, as 
depicted in Figure 10-6. Be sure that you can ping the router's local LAN and WAN interface before 
moving on. Do not forget to use the clock rate command for the DCE side on the serial interfaces of 
the sea_shepherd router. 


The basic |GRP configuration is similar on all the routers. Following the three-step process for |GRP 
configuration provided earlier in the chapter, begin by enabling |GRP on all the routers by using the 
router |GRP 65001 command. The second step is to define the networks to run IGRP on. The 
sea_shepherd router runs I|GRP on major networks 204.30.121.0 and 172.16.0.0. The ocean_ warrior 
router runs IGRP on networks 110.0.0.0 and 172.16.0.0. The mirage and sirenian routers need to run 
IGRP on only the 172.16.0.0 network. Example 10-14 shows the initial |GRP configuration on the 


routers. 


Example 10-14 Initial |GRP Configuration for Neptune Naval Intelligence 
Network Routers 


hostname sea_shepherd 
! 


router igrp 65001 “Define the IGRP process 
“network 172.16.0.0 ‘Networks participating in routing 


network 204.30.121.0 


hostname ocean_warrior 
! 

router igrp 65001 
network 110.0.0.0 
network 172.16.0.0 


hostname sirenian 

! 

router igrp 65001 
network 172.16.0.0 
! 


hostname mirage 

! 

router igrp 65001 
network 172.16.0.0 
! 


At this point, full routing should exist between all the routers. Verify this with the show ip route 
command and by pinging the various interfaces. The route table on the sea_shepherd router 
resembles Example 10-15. 
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Example 10-15 Route Table of the sea_ shepherd Router 


sea_shepherd#show ip route 
<<<text omitted>>> 
Gateway of last resort is not set 


Cc 204.30.121.0/24 is directly connected, Ethernet0O 
172.16.0.0/24 is subnetted, 4 subnets 
172.16.128.0 [100/8676] via 172.16.2.5, 00:00:32, Serial0O 
172.16.10.0 [100/8576] via 172.16.2.5, 00:00:56, SerialO 
172.16.1.0 is directly connected, Serial7 
172.16.2.0 is directly connected, Serial0O 
sea_shepherd# 


on @ Sa 


If you observe the routing table on the mirage router, as in Example 10-16, you can see that two 
routes exist to the network 204.30.121.0/24. One route travels through ocean_warrior, 172.16.10.1, 
and one route travels through sirenian. Two routes exist because the default bandwidth has not been 
changed on the serial interfaces, so |GRP has inconsistent views of the metrics for the routes. To 
enforce consistent metrics, the bandwidth statement needs to be added to the serial interface on 
the WAN links. Without bandwidth statements, the sirenian and ocean_warrior routers view both of 
their links as the Tls. The sea_shepherd router in this example is a Cisco 2522, so the low-speed 
sync port measures yet a different default metric of 115 for the bandwidth. This reaffirms why you 
should check and configure the bandwidth statements for proper routing. 


Example 10-16 mirage Router Routing Table 


mirage#show ip route 
<<<text omitted>>> 
Gateway of last resort is not set 


172.16.0.0/24 is subnetted, 4 subnets 
172.16.128.0 [100/1200] via 172.16.10.1, 00:01:10, Ethernet0/1 
172.16.10.0 is directly connected, Ethernet0/1 
172.16.1.0 [100/8576] via 172.16.10.1, 00:00:41, Ethernet0/1 
172.16.2.0 [100/8576] via 172.16.10.5, 00:00:44, Ethernet0/1 


HHOAH 


mirage# 


After adding bandwidth statements to the serial interfaces, the mirage router shows a preferred 
route to the 204.30.121.0/24 network through the sirenian router or 172.16.10.5. Example 10-17 
lists the output of the show ip route command after the statements bandwidth 64 and bandwidth 
1544 to the serial interfaces of the ocean_warrior and sirenian routers, respectively. The statements 
is also added to the sea_shepherd router. 


Example 10-17 mirage Routing Table After the bandwidth Statements Are 
Added 


mirage#show ip route 
<<<text omitted>>> 
Gateway of last resort is not set 


172.16.0.0/24 is subnetted, 4 subnets 
172.16.128.0 [100/1200] via 172.16.10.1, 00:01:10, Ethernet0O/1 
172.16.10.0 is directly connected, Ethernet0/1 
172.16.1.0 [100/158350] via 172.16.10.1, 00:01:10, Ethernet0/1 
172.16.2.0 [100/8576] via 172.16.10.5, 00:00:19, Ethernet0/1 


HH OH 


mirage# 
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The next step in the lab is to configure a default network on the sea_shepherd router. To achieve 
this, add the global command ip default-network 204.30.121.0 on the sea_shepherd router. 
Remember, for a router to use a default route, ip classless also must be enabled. Viewing the route 
table on the mirage router, the default network is now set with the *, and a gateway of last resort is 
also set to network 204.30.121.0. Example 10-18 lists the routing table of mirage after the default 


network is set on the sea_shepherd router. 


Example 10-18 mirage Routing Table After the Default Network Is Set on 
sea_ shepherd 


mirage#show ip route 
<<<text omitted>>> 
Codes: C - connected, S - static, I - IGRP, R —- RIP, M —- mobile, B —- BGP 
D — EIGRP, EX -— EIGRP external, O —- OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U - per-user static route, o - ODR 


172.16.0.0/24 is subnetted, 4 subnets 
172.16.128.0 [1000/1200] via 172.16.10.1, 00:03:06, Ethernet0/1 
172.16.10.0 is directly connected, Ethernet0/1 
172.16.1.0 [100/158350] via 172.16.10.1, 00:01:18, Ethernet0/1 
172.16.2.0 [100/8576] via 172.16.10.5, 00:00:27, Ethernet0/1 
110.0.0.0/8 [100/1200] via 172.16.10.1, 00:01:18, Ethernet0/1 


Ho A! A 


mirage# 


Another task of this lab is to configure unequal-cost load balancing to the default network from the 
mirage router. Recalling the process from an earlier section, you need to set the bandwidth and then 
derive and configure the variance. You have already accomplished the first step by taking the extra 
time to tune the IGRP configuration with the bandwidth statements earlier in the lab. For the second 
step, you need to derive the variance. The variance formula is as follows: 


1 + ({highest_cost_path/lowest_cost_path] Rounded up) 


Use debug ip igrp transactions to find the lowest-cost metric to 204.30.121.0/24. Example 10-19 
shows the output of the command on the ocean_ warrior router. 


Example 10-19 debug ip igrp transactions Command Output on the 
ocean_ warrior Router 


ocean_warrior#debug ip igrp transactions 

IGRP protocol debugging is on 

ocean_warrior# 

04:35:06: IGRP: received update from 172.16.1.4 on Seriall 

OAs 352065 subnet 172.16.10.0, metric 160350 (neighbor 8576) 
042352062 subnet 172.16.2.0, metric 160250 (neighbor 8476) 


— 
dS Se ened ee | 


04:35:06: IGRP: received update from 172.16.10.9 on Ethernet4 
04235206¢ subnet 172.16.10.0, metric 1200 (neighbor 1100) 
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042355062 subnet 172.16.2.0, metric 8676 (neighbor 8576) 
_— 


In this model, you have 1 + (158350/8776) = 20. After the variance is set, the router reports two 
paths to the destination network and load-shares over them. Example 10-20 shows the route table of 


the ocean_warrior router after the variance 20 command was added under the |GRP process. 


Example 10-20 show ip route Command Output on the ocean_ warrior Router 


ocean_warrior#show ip route 
<<<text omitted>>> 
Gateway of last resort is 172.16.1.4 to network 204.30.121.0 


172.16.0.0/24 is subnetted, 4 subnets 
172.16.128.0 is directly connected, Ethernet3 
172.16.10.0 is directly connected, Ethernet4 
172.16.1.0 is directly connected, Seriall 
172.16.2.0 [100/160250] via 172.16.1.4, 00:00:11, Seriall 
[100/8576] via 172.16.10.5, 00:00:34, Ethernet4 


HOO © 


ocean_warrior# 


Next, you need to filter the ocean_warrior subnet of 110.16.20.0/24 from the mirage router. You 
need to configure distribute lists on the ocean_ warrior router and the sirenian router. Example 10-21 
shows the configuration of the ocean_ warrior distribute list. The distribute list on the sirenian router 
is identical except for the Ethernet port. 


Example 10-21 Configuration of the Distribution List on ocean_ warrior 


ocean_warrior (config) #router igrp 65001 

ocean_warrior (config-router) #distribute-list 10 out e4 
ocean_warrior(config-router) #exit 
ocean_warrior (config) #access-list 10 deny 172.16.128.0 0.0.0.255 
ocean_warrior (config) #access-—list 10 permit any 


When the 172.16.128.0/24 route is filtered out the Ethernet port on the ocean_warrior router, 
sirenian tries to route to this route through the sea_shepherd router. A static route can be added to 
sirenian to prevent this. Example 10-22 now lists the route table of the mirage router without the 


172.16.128.0/24 subnet. 


Example 10-22 Route Table of the mirage Router, After the Filter 


mirage#show ip route 
<<<text omitted>>> 
Gateway of last resort is 172.16.10.5 to network 204.30.121.0 


172.16.0.0/24 is subnetted, 3 subnets 


Cc 172.16.10.0 is directly connected, Ethernet0/1 
T 172.16.1.0 [100/158350] via 172.176.10.1, 00:00:08, BRthernéet0/1 
i 172.16.2.0 [100/8576] via 172.16.10.5, 00:00:27, Ethernet0/1 


r* 204.30.121.0/24 [100/8676] via 172.16.10.5, 00:00:27, Ethernet0/1 
mirage# 
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Finally, the optional portion of the lab involves limiting broadcasts on the Ethernet segment between 
the routers. Broadcast can be limited by enabling unicast routing updates. The neighbor a.b.c.d 
statement, along with the passive interface command, causes only unicast routing updates to 
occur. The last example lists the final router configs, which includes the unicast configuration. 


Example 10-23 Final Router Configurations for Neptune Naval Intelligence 
Network Routers 


hostname sea_shepherd 
! 
interface Ethernet0 
ip address 204.30.121.30 255.255.255.0 
! 
interface Serial0 
ip address 172.16.2.4 255.255.255.0 
bandwidth 1544 
no fair—queue 
clockrate 2000000 
! 
interface Serial7 
ip address 172.16.1.4 255.255.255.0 
bandwidth 64 
clockrate 64000 
! 
router igrp 65001 
network 172.16.0.0 
network 204.30.121.0 
! 
ip classless 
ip default-network 204.30.121.0 
! 


hostname ocean_warrior 
! 
interface Ethernet3 
ip address 172.16.128.1 255.255.255.0 
media-type 10BaseT 
! 
interface Seriall 
ip address 172.16.1.1 255.255.255.0 
bandwidth 64 
! 
router igrp 65001 
variance 20 
passive-interface Ethernet4 
network 110.0.0.0 
network 172.16.0.0 
neighbor 172.16.10.5 
neighbor 172.16.10.9 
distribute-list 10 out Ethernet4 
! 
ip classless 
! 
access-list 10 deny 172.16.128.0 0.0.0.255 
access-list 10 permit any 


hostname sirenian 
! 
interface Ethernet0 


663 


ip address 172.16.10.5 255.255.255.0 
no ip directed—-broadcast 

! 

interface Serial0O 

ip address 172.16.2.5 255.255.255.0 
bandwidth 1544 

no ip directed—-broadcast 

no ip mroute-cache 

no fair-queue 

! 
router igrp 65001 

passive-interface Ethernet0O 

network 172.16.0.0 

neighbor 172.16.10.1 

neighbor 172.16.10.9 

distribute-list 10 out EthernetO 

! 
ip classless 
ip route 172.16.128.0 255.255.255.0 172.16.10.1 


hostname mirage 
! 
interface Ethernet0/1 
ip address 172.16.10.9 255.255.255.0 
! 
router igrp 65001 
passive-interface Ethernet0/1 
network 172.16.0.0 
neighbor 172.16.10.5 
neighbor 172.16.10.1 
! 
ip classless 


To verify unicast updates, perform a debug ip igrp transactions command on the sirenian or 
ocean_warrior routers. By performing this command on the sirenian router in Example 10-24, notice 
how the updates out the Ethernet O port are no longer sent to a broadcast address or 
255.255.255.255, but instead are sent to a specific address as specified in the neighbor statement. 


Example 10-24 Verifying Unicast Updates 


sirenian#debug ip igrp transactions 
IGRP protocol debugging is on 


sirenian# 

OL SOs 4 0% subnet 172.16.10.0, metric=1100 

OL 01740 subnet 172.16.1.0, metric=158350 
OLS OL sails subnet 172.16.10.0, metric=1100 

OL SOls4 12 subnet 172.16.1.0, metric=158350 
OLS 'O1 24s subnet 172.16.2.0, metric=8476 

OLS 01.412 exterior 204.30.121.0, metric=8576 
OLSOL 41% subnet 172.16.10.0, metric=1100 
OLS O01 4s subnet 172.16.2.0, metric=8476 

O1s 01.413 exterior 204.30.121.0, metric=8576 
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Chapter 11. Hybrid: Enhanced Interior Gateway 
Routing Protocol (EIGRP) 


As internetworks grew in scale and diversity in the early 1990s, new routing protocols were 
needed. Cisco developed Enhanced Interior Gateway Routing Protocol (IGRP) primarily to 
address many of the limitations of |GRP and RIP. As WANs were growing, so was the need for 
a routing protocol that would use efficient address space on WAN links, as well as the LAN 
networks. OSPF was available, but the CPU-intensive tasks that it had to perform often 
overloaded the small processors of many edge or remote routers of that time. The 
configuration was also more complex than that of RIP or IGRP. A routing protocol was needed 
that could support VLSM and that could scale with large internetworks, yet that was less CPU- 
intensive than OSPF. In 1994, Cisco answered the call by releasing Enhanced IGRP in Cisco 
10S Software Release 9.21. Today, EIGRP is used as the routing protocol on many large 
government and commercial internetworks. It has proven to be very stable, flexible, and fast. 
In addition to these characteristics, the ease of EIGRP configuration makes it one of the most 
popular routing protocols among network engineers. 


EIGRP can be referred to as a hybrid protocol. It combines most of the characteristics of 
traditional distance vector protocols with some characteristics of link-state protocols. 
Specifically, EIGRP is "enhanced" by using four routing technologies: 


Neighbor discovery/recovery 
Reliable Transport Protocol (RTP) 
DUAL finite-state machine 
Protocol-dependent modules 


This chapter covers these technologies, as well as the operation and configuration of EIGRP. 


665 


Technical Overview of EIGRP 


EIGRP offers many advantages over other routing protocols, including the following: 


e Support for VLSM— EIGRP is a classless routing protocol and carries the subnet mask of the 
route in its update. 


e Rapid convergence— By using the concept of feasible successors, defined by DUAL, EIGRP is 
capable of preselecting the next best path to a destination. This allows for very fast convergence 
upon a link failure. 


e Low CPU utilization— Under normal operation, only hellos and partial updates are sent across 
a link. Routing updates are not flooded and are processed only periodically. 


e Incremental updates— EIGRP does not send a full routing update; it sends only information 
about the changed route. 


e Scalable— Through the use of VLSM and a complex composite metric, E1GRP networks can be 
vast in size. 


e Easy configuration— EIGRP supports hierarchical network design, but it does not require the 
strict configuration guidelines, such as the ones needed for OSPF. 


e Automatic route summarization— EIGRP will perform automatic summarization on major bit 
boundaries. 


e MD5 route authentication— As of Cisco |OS Software Release 11.3, EIGRP can be configured 
to perform MD5 password authentication on route updates. 


Looking at this list, it becomes evident why EIGRP has become a popular routing protocol. It provides 
many of the enhancements of OSPF, without the strict configuration guidelines. It could be argued that 
EIGRP's weakest point is that it is a Cisco-proprietary protocol, but with the aid of redistribution, this 
point becomes moot. 


EIGRP is a classless routing protocol. It directly interfaces to IP as protocol 88. EIGRP uses the 
multicast address of 224.0.0.10 for hellos and routing updates instead of an all-hosts broadcast like RIP 
uses. EIGRP also employs a system of hello and hold timers to maintain neighbors. Aside from the 
initial routing update, partial routing updates are sent only when network topology changes occur. The 
updates are also bounded, which means that updates are sent only to pertinent routers. Like IGRP, 
EIGRP uses a composite metric to calculate the best path to a destination. The sections that follow take 
a closer look at how EIGRP makes use of metrics, neighbors, reliable transport, and DUAL in its 
operation. 


NOTE 


Early releases of EIGRP had stability issues over low-speed serial links and problems 
maintaining many neighbors. Cisco significantly enhanced EIGRP with Cisco |OS Software 
Releases 10.3(11), 11.0(8), and 11.1(3)— early releases of EIGRP are sometimes referred 
to as EIGRP version 1. Cisco currently ships routers with 1OS 12.0 and above. 


EIGRP Metrics 


EIGRP uses metrics in the same way as IGRP. Each route in the route table has an associated gegtric: 


EIGRP uses a composite metric much like IGRP, except that it is modified by a multiplier of 256. Recall 
from Chapter 10, "Distance Vector Protocols: Interior Gateway Routing Protocol (EIGRP)," that 


bandwidth, delay, load, reliability, and MTU are the submetrics. Like I|GRP, EIGRP chooses a route 
based primarily on bandwidth and delay, or the composite metric with the lowest numerical value. 
When EIGRP calculates this metric for a route, it calls it the feasible distance to the route. EIGRP 
calculates a feasible distance to all routes in the network. The following list is a detailed description of 
the five EIGRP submetrics: 


e Bandwidth— Bandwidth is expressed in units of kilobits. It must be statically configured to 
accurately represent the interfaces that EIGRP is running on. For example, the default 
bandwidth of a 56-kbps interface and a T1 interface is 1544 kbps. To accurately adjust the 
bandwidth, use the bandwidth kbps interface subcommand. Table 11-1 highlights some 
common bandwidth values. 


e Delay— Delay is expressed in microseconds. It, too, must be statically configured to accurately 
represent the interface that EIGRP is running on. The delay on an interface can be adjusted with 
the delay time_in_microseconds interface subcommand. Common delay values are represented 
in Table 11-1. 


e Reliability— Reliability is a dynamic number in the range of 1 to 255, where 255 is a 100 
percent reliable link and 1 is an unreliable link. 


e Load— Load is the number in the range of 1 to 255 that shows the output load of an interface. 
This value is dynamic and can be viewed using the show interfaces command. A value of 1 
indicates a minimally loaded link, whereas 255 indicates a 100 percent loaded link. 


e MTU— The maximum transmission unit (MTU) is the recorded smallest MTU value in the path, 
usually 1500. 


NOTE 


Whenever you are influencing routing decisions in |GRP or EIGRP, use the metric of delay 
over bandwidth. Changing bandwidth can affect other routing protocols, such as OSPF. 
Changing delay affects only IGRP and EIGRP. 


Table 11-1 highlights the common metrics used. 


Table 11-1. Common IGRP and EI GRP Metrics 


| Medium | Bandwidth Delay 
/100-Mbps ATM [100,000 kbps 100 microseconds 
Gigabit Ethernet [100,000 kbps 100 microseconds 
Fast Ethernet /100,000 kbps 100 microseconds 
|FDDI [100,000 kbps 100 microseconds 
/HSSI 45,045 kbps 20,000 microseconds 
/16- Mbps Token Ring [16, 000 kbps 630 microseconds 
a Mbps Ethernet [10, 000 kbps 1000 microseconds 
[T1 [1544 kbps 20,000 microseconds 
DS- 0 [6 4 kbps 20,000 microseconds 
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[56- kbps media [56 kbps 20,000 microseconds 


EIGRP uses a composite metric (CM) that is derived from the five submetrics. When EIGRP computes 
the composite metric, it uses a formula that involves five constants or "k" values. The constant values 
have default value such as the following: 


kl] =k3 =1 andk2 =k4=k5=0 


By setting k2, k4, and k5 to 0, it essentially nullifies the submetrics of load, reliability, and MTU. This is 
precisely why you should first use delay and then bandwidth when trying to influence which routes 
EIGRP prefers. The formula EIGRP uses to calculate the composite metric is as follows: 


CM = 256 x ([k 1 X BW yin + (K2. X BW yin) / (256-LOAD) + k3 X DELAY gun] XX) 


where the following is true: 


BW nim = 10’ / bandwidth_of_slowest_link 
DELAY .y,,, = 2 (delays_along_the_path) 
X = k5 / (reliability + k4) if and only if kl<>1, if kl = 1 then X = 1 


With the k values set at the default value you have 


kl=k3=1 
k2=k4=k5=0 
CM = 256 x (BW,,;, + DELAY,,,,) 


NOTE 


The router calculation of the composite metric will always differ slightly from the result 
when it is performed by longhand. This is because of the way the router handles floating- 
point mathematics; there will be slight rounding discrepancies. 


Using the default values of constants, kl = k3 = 1 and k2 = k4 = k5 =0, the formula quickly breaks 
down to this: 


(256 x [BW,,;,, and DELAY ,,,,1) 
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Substituting the constants, you have the following: 


CM = 256 x ([1 X BWiyin + (0 BWyyi) / (256-LOAD) + 1 X DELAY gun] X 1) 
CM = 256 x ([BW yi, + (0) / (256-LOAD) + DELAY,,,,] 1) 
CM = 256 X (BW yin + DELAY gum) 


NOTE 


For reference, the metric is computed the same way for IGRP, except the result of 
bandwidth and delay is not multiplied by 256, and the DELAY.,,,, variable is divided by 10. 


CM = 256 x ([kl X BW yi + (K2 X BW yin) / (256-LOAD) + k3 X DELAY gun] ¥ X) 


mim 


where the following is true: 


BW in = 10’ / bandwidth_of_slowest_link 

DELAY .y,, = S(delays_along_the_path) / 10 

X = k5 / (reliability + k4) if and only if kI<>1, if kKl=1 then X=1 
k1=k3=1 

k2=k4=k5=0 


With k values set at the default value, you have: 


CM = BW,,;, + DELAY, 


To demonstrate composite metric calculation, refer to Figure 11-1. In this example, EIGRP calculates a 
composite metric on the alpha router to 172.16.1.0/24, which resides on the charlie router. 


Figure 11-1. EIGRP Routing Updates 
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Assuming that the bandwidth statements been set by an astute engineer, the lowest bandwidth on 
the path between alpha and charlie routers would be 56. Therefore, you have 


BW,,;7 = 10/ / 56 = 178571 


The delay is the summation of the delays on the outbound interfaces only. The summation ends with 
the delay on the interface in which the final subnet resides. From alpha to bravo, the delay is 20000; 
from bravo to charlie, it is 1000; this includes the final interface on charlie, which has a delay of 1000. 
Therefore, you have 


DELAY,,,,, = 20000 + 1000 + 1000 = 22000 


The composite metric now yields the following: 


CM = 256 x (178571) + 256 x (22000) = 46277485 


The submetrics and the composite metric can be confirmed by performing the show ip route. 


172.16.1.0 command on the alpha router, as in Example 11-1. Remember, because of rounding 
errors, the metric does not match exactly. 


Example 11-1 show ip route Command Output Highlighting the EI GRP Metrics 


alpha#show ip route 172.16.1.0 
Routing entry for 172.16.1.0/24 


Redistributing via eigrp 65001 
Last update from 172.16.3.1 on Serial7, 00:50:53 ago 
Routing Descriptor Blocks: 
* 1172.16.31, £rom 172.16.3.1, O0°;50753 ago, via Serial y 
Route metric is 46277376, traffic share count is 1 
Total delay is 22000 microseconds, minimum bandwidth is 56 Kbit 
Reliability 255/255, minimum MTU 1500 bytes 
Loading 1/255, Hops 2 


alpha# 


When using metrics to influence routing decisions, use the delay xx interface command. Be sure to 
include a delay at each side of the interface if you want symmetrical routing—that is, packets will take 
the same route back to the source. By default, EIGRP will perform equal-cost load balancing over 
routes. For example, if you perform a show ip route command and see two routes to a destination 
reported, EIGRP will load-balance over those routes. 


To demonstrate the use of the delay metric, we have added another Ethernet segment between the 
bravo and charlie routers and a loopback interface, 172.16.128.1/24, on the charlie router, as 
illustrated in Figure 11-2. 


Figure 11-2. E1GRP Load Sharing 


EIGRP 

65001 

56 56 
alpha ont oot, bravo 
Bancweth « Bandwkth « 4% 
S4-1P-172.16.3.2/90 
$1-IP-172.16.3.1/30 
E4IP-172. 16.22/24 


ES-IP-172.16,16,2/24 


10 Mies 
Detay «1000 
~ 10000 


| 


E0/0-IP-172.16.16.1/24 SOEPATE. OS 


charlie 


Loopback 20 
IP-172.16.128.1/24 


If you perform a show ip route command on the bravo router, as shown in Example 11-2, you see 
two routes to the 172.16.128.0/24 network. The show ip eigrp topology command also lists the 
routes and the composite metric to them. 671 


Example 11-2 Two Routes Reported to 172.16.128.0/ 24 


bravo#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B —- BGP 
D — EIGRP, EX -— EIGRP external, O - OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
Kl = OSPF external type 1, E2 = OSPF external type 2, EH — EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U - per-user static route, o — ODR 


Gateway of last resort is not set 


172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks 


D 172.16.128.0/24 [90/409600] via 172.16.2.1, 00:23:50, Ethernet4 
[90/409600] via 172.16.16.1, 00:23:50, Ethernet5 

ic 172.16.16.0/24 is directly connected, Ethernet5 

Cc 172.16.2.0/24 is directly connected, Ethernet4 

Cc 172.16.3.0/30 is directly connected, Seriall 

bravo# 


If you want EIGRP to prefer one path to the other, add the delay command on each side of the 
interface. It is important to note that changing the delay of a link will affect only the routing protocol, 
not the actual throughput of the link. 


Continuing with the example, set the delay of the link so that the primary link to 172.16.128.0 will be 
through 172.16.16.1. This can be accomplished by adding a delay of 1000 to the e4 interface of the 
bravo router and under the e0/1 interface of the charlie router. Example 11-3 demonstrates the 


configuration of delay on the bravo router. 


Example 11-3 Addition of the delay Command 


bravo#conft t 

Enter configuration commands, one per line. End with CNTL/Z. 
bravo(config) #int e4 

bravo (config-if)#delay 1000 

bravo (config-if) #*Z 


Example 11-4 shows the route table of the bravo router after the delay was added to the bravo and 
charlie routers. 


Example 11-4 One Route to the 172.16.128.0/ 24 Route 


bravo#show ip route 
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks 


D 172.16.128.0/24 [90/409600] via 172.16.16.1, 00:00:11, Ethernet5 
Cc 172.16.16.0/24 is directly connected, Ethernet5 

c 172.16.2.0/24 is directly connected, Ethernet4 

Cc 172.16.3.0/30 is directly connected, Seriall 

bravo# 


Keep in mind that although the second route is removed from the routing table, EIGRP still knows of 
the route and will keep it as a feasible successor. 


The k values also can be manipulated to influence routing decisions. This can be accomplished with the 
metric weights tos k1 k2 k3 k4 k5 command. Manipulating these values directly impacts how EIGRP 
derives the composite metric for all routes. Change the metric weights only when working with Cisco to 
solve specific problems. 672 


EIGRP Neighbors 


EIGRP does not periodically advertise it routes. Because of this, it needs some way to locate and then 
exchange routing information with adjacent devices. EIGRP accomplishes this through the use of 
neighbors. When EIGRP initializes, it sends out a multicast hello on address 224.0.0.10, on broadcast 
media. On NBMA media, X.25, Frame Relay, and ATM, the hellos are unicast every 60 seconds. El GRP 
continues to send out hellos every few seconds, based on the media type. Specifically, El1GRP sends 
hellos every 5 seconds on the following interfaces: 


LAN broadcast media, such as Ethernet, Token Ring, and FDDI 

High-speed serial link greater than Tl speeds, such as Frame Relay HSSI links 
Point-to-point serial links, such as PPP or HDLC 

ATM and Frame Relay point-to-point subinterfaces 


EIGRP sends hellos every 60 seconds on the following interfaces: 


e Low-speed serial links less than Tl speeds, including Frame Relay and multipoint X.25 
e ATM and Frame Relay multipoint interfaces, and ATM SVCs 
e ISDN BRIs 


Routers that reside on the same network receive the multicast hello and respond to form what is called 
an adjacency. Figure 11-3 and the list that follows describe the initial router exchange when forming an 
adjacency: 


Figure 11-3. EI1GRP Neighbor Establishment 
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1. Hellos are sent out each interface participating in EIGRP, except interfaces quieted by the 
passive interfaces. All EIGRP hellos and routing updates use the multicast address of 224.0.0.10. 
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2. Routers on the same IP subnet receive the multicast and respond with a full routing update. 
This is accomplished by setting the INITialization bit in the EIGRP header; the updates include 
all networks that EIGRP is aware of and the metric for those routes, except for those suppressed 
by split horizon. This update packet establishes a neighbor relationship (adjacency). The hello 
packet also includes a hold timer, which tells the router how long it should wait before receiving 
a hello and declaring the route unreachable and reporting it to the DUAL process. The hold timer 
is set to three times the value assigned for the hello timer. This usually is 15 or 180 seconds, 
depending on the media. 


3. The bravo router responds to the initialization packet by sending a hello with the ACK bit set. 
EIGRP sets the ACK bit to acknowledge all messages that it receives that have data. This is one 
way that EIGRP has reliable transports (discussed further in upcoming sections). 


4. The bravo router now inserts the new update into its route table. Because it has a new update, 
it sends an update to all its neighbors. 


5. The neighbors that received the update from the bravo message respond with an 
acknowledgment packet. 


6. The router holds the adjacency by the continuous exchange of hellos. If a hello is not received 
by the time the hold timer expires, the router marks the route as unreachable. 


When the router forms an adjacency, it treats this as a virtual link to transport routing information. 
The router begins to form a neighbor table with the following information: 


The IP address of the router that it received the hello from 
The hold timer 

The SRTT or round-trip time 

The uptime of the neighbor 


The status of neighbors can be displayed with the show ip eigrp neighbors command, as in Example 
11-5. The uptime of the neighbor should be for as long as the adjacency has been established. 


Example 11-5 show ip eigrp neighbors Command Output on the bravo Router 


bravo#tshow ip eigrp neighbors 
IP-EIGRP neighbors for process 65001 


H Address Interface Hold Uptime SRIT RTO Q Seq 

(sec) (ms ) Cnt Num 
1 VIZ LG si Et4 12 01810236 8 200° 0. 29 
2 7216.16. BeS 13 02514315 3 200 O 28 
0 D2 VG. Bt Sel 11 07:07:44 23 2604 0 23 
bravo# 


Stable EIGRP neighbors are the single most important element in any EIGRP network. Without stable 
neighbors, an EIGRP network will have difficulty operating properly. Checking the status of EIGRP 
neighbors should be the first step in verifying the operational status of any EIGRP network. 


EIGRP Reliable Transport Protocol (RTP) 


RTP ensures that EIGRP packets are received, delivered, ordered, and acknowledged. To guarantee 
delivery, EIGRP employs the use of a Cisco proprietary reliable multicast message. When each neighbor 
receives a reliable multicast packet, it is required to respond with a unicast acknowledgment. Updates 
also have sequence numbers; this is how the router ensures that updates are in the proper order. To 
facilitate RTP and the other functions of EIGRP, Cisco uses four primary types of packets, even though 
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there are actually five. As previously mentioned, all EIGRP packets directly interface with the IP layer 
as protocol 88, and the multicast updates use the IP address of 224.0.0.10. The five packet types are 
as follows: 


e Hello— Used to discover and maintain neighbors. This packet type uses unreliable delivery. 


e Acknowledgments (ACKs)— Used to acknowledge updates. They are essentially hellos with 
no data in them. ACKs also use unreliable delivery. 


e Updates— Contain routing information. Updates can be either unicast or multicast, depending 
on how they are generated. Updates use reliable delivery. 


e Queries— Used by the DUAL process to find feasible successor for routes. The query can be 
unicast or multicast. Queries always use reliable delivery. 


e Replies— Used by the DUAL process to aid in finding feasible successor for routes. Replies are 
always unicast and use reliable delivery. 


NOTE 


Some documentation refers to queries and replies as the four and fifth types of packets. 
The actual fifth type of packet is a request. The request never was implemented in EIGRP 
and was intended for route servers. IPX SAPs also use another Opcode in the El GRP 
header, making them another packet type. 


Diffusing Update Algorithm 


The DUAL algorithm is the "brains" of EIGRP, responsible for tracking all routes by all neighbors and 
ensuring a loop-free topology. It is based on an algorithm first developed by E.W. Dijkstra and C.S. 
Scholten, and later enhanced by J.J. Garcia-Luna-Aceves. 


With the help of DUAL, EIGRP and the processes previously covered, EIGRP keeps the following tables: 


e Neighbor table— EIGRP tracks every formed adjacency in the neighbor table. A neighbor will 
be held until an ACK is not received after 16 unicast retransmissions to that neighbor. At this 
time, the neighbor is dropped. Neighbors can be displayed with the show ip eigrp neighbors 
command. 


e Topology table— All learned routes reported by neighbors are kept in the topology table. The 
topology table also tracks the metrics and feasible distances associated with those routes. The 
topology table can be displayed with the show ip eigrp topology as_ number command. 


e Route table/ forwarding table— Only the routes with the lowest composite metric are 
entered into the final route or forwarding table. This is the route that the router will forward to. 


The process that DUAL uses to perform a loop-free topology is a detailed process. EIGRP has what is 
called a feasible successor and a successor to every route in its route table. The successor is the 
primary path for the route, or the path that the router will forward packets to. The feasible successor 
becomes the next-hop address only if the primary route to the destination becomes unreachable. The 
feasible successor is always downstream and, thereby, must have a distance or feasible distance that is 
less than that of the current preferred route. This prevents routing loops because the downstream 
router must always have a feasible cost lower than that of the current cost of the route to be 
considered as a feasible successor. 
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The DUAL process is in control of determining feasible distances, feasible successors, and the successor 
of the routes in the EIGRP topology table. By having a backup path already defined in the topology 
table, the router can quickly converge to the new path in case the primary path fails. 


Protocol-Dependent Modules 


EIGRP is one of the few routing protocols that can work with multiple routed protocols. Cisco 
implements what it calls protocol-dependent modules in the code that handle protocol-specific tasks. 
For example, |PX EIGRP needs to send and receive SAP updates. IP and IPX form neighbors using 
different message formats. 


EIGRP operates the same way for all routed protocols—that is, it uses DUAL to find the shortest path to 
forward data toward. Another task of protocol-dependent modules is to pass data into the DUAL 
process so that a proper topology table, and eventually a route table, can be formed. 


Like I|GRP, EIGRP deploys the concepts of split horizon and poison reverse to prevent routing loops. 
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Split Horizon 


Recall from earlier that split horizon is a routing technique in which information about routes 
is prevented from exiting the router interface or subinterface through which that information 
was received. Split horizon is most prevalent in multipoint networks. Here, routing updates 
flow into one subinterface but also must be sent out that very same subinterface to reach the 
other routers on the multipoint network. Split horizon is enabled by default and prevents 
specific route updates for EIGRP, |GRP, and RIP from being propagated properly in a 
multipoint configuration. Disable this with the no ip split-horizon eigrp autonomous system 
command. This command has similar forms for |PX and AppleTalk. 


In Figure 11-4, the grinch router receives updates from the whos and whoville routers, but 
because of split horizon, the grinch does not advertise 172.16.5.0 and 172.16.6.0 out its 
serial 0.1 multipoint interface. Because the grinch didn't learn about the 172.16.2.0 network 
from its 0.1 interface, it advertises that network to the whos and whoville routers. 


Figure 11-4. EIGRP Split Horizons Route Suppression 
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To make the whos and whoville happy again, we need to disable split horizon on the grinch 
by using the no ip split-horizon eigrp command, as demonstrated in Example 11-6. 


Example 11-6 Disabling Split Horizon on the grinch Router 
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grinch(config) #int s0.1 
grinch (config-subif)#no ip split-—-horizon eigrp 2001 


Figure 11-5 illustrates how the routing tables will look after disabling split horizon on the 
grinch router. Notice that all routes are being propagated. 


Figure 11-5. Fully Functional El GRP Network 
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Configuring EIGRP 


Configuring basic EIGRP is, for the most part, identical to configuring |GRP. Configuring 
EIGRP calls for the definition of an autonomous system (AS). By definition, an AS is a set of 
routers under a single administrative technical authority. Like |GRP, EIGRP uses the concept 
of ASs to separate routing processes. Having a registered AS when configuring EIGRP is not 
required. 


This following three-step process can be used to configure EIGRP. The third step is optional 
to specific environments. 


Step 1. Enable EIGRP and define an AS on the router. This is accomplished with the 
router eigrp autonomous_system_id global command. 


Step 2. Add the networks that you want to run EIGRP on. This is accomplished with 
the network a.b.c.d from the config-router# mode. When you enter the network 
statements, it is necessary to enter only the major class boundary. In Cisco |1OS 
Software Release 12.0 and later, the network command adds an additional wildcard 
mask, much like OSPF. This is an inverse bit mask—for example, to enable EIGRP on 
network 172.16.1.0 only, the syntax would be network 172.16.1.0 0.0.0.255; 
however, note that EIGRP is smart enough to convert a subnet mask to a wildcard 
mask if you make a mistake. Now that's user-friendly! 


Step 3. (Optional) Fine-tune EIGRP metrics with bandwidth statements, or configure 
IGRP summarization and options. By taking the time to configure bandwidth, ElGRP 
will have a more accurate picture of the network and also will aid in preventing ElGRP 
from saturating the link with broadcasts. The bandwidth always should be set on 
Frame Relay networks. The bandwidth can be changed with the bandwidth kilobits 
interface command. Later sections in the chapter cover bandwidth and summarizing 
EIGRP in greater detail. 


Example 11-7 illustrates the EIGRP configuration from Figure 11-5 on the grinch router. 


Example 11-7 EIGRP Configuration 


! hostname grinch 

! 

interface Ethernetl 

ip address 172.16.2.1. 255.255.255.0 
media-type 10BaseT 

! 
interface Serial0 

no ip address 

encapsulation frame-relay 

no ip mroute-cache 

! 
interface Serial0O.1 multipoint 

ip address: 172.16.1.1. 255.255.255.0 


no ip split-horizon eigrp 2001  *~ split Horizons disabled 

bandwidth 112 = ¥ Bandwidth set to the sum of the remote PVCs 
frame-relay map ip 172.16.1.5 110 broadcast 

frame-relay map ip 172.16.1.6 130 broadcast 
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! 

router eigrp 2001 “ EIGRP._ routing process 
-network 172.16.0.0 “Networks running BIGRP 
! 


Before further discussing these and other EIGRP options in greater detail, lets take a closer 
look at the show commands for EIGRP. 
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The "Big show" and "Big D" for EIGRP 


Cisco offers some useful tools for determining how EIGRP is working. Perhaps one of the best and most 
overlooked commands is show ip eigrp neighbors. ElGRP neighbors remind me of an old Robert Frost 
poem that said, "Good fences make good neighbors." Well, in EIGRP, "Good networks make good 
neighbors." The neighbor state is absolutely critical to EIGRP operations. Besides providing the 
capability to assess neighbor states, Cisco offers tools to look at the EIGRP topology table, as well as 
providing detailed logging of EIGRP events. 


The following is a list of what we find to be the most useful show, logging, and debug commands for 
El GRP: 


show ip eigrp neighbors [as_number | interface_name] 

show ip eigrp topology [as_number | active | pending | summary] [as_number subnet 
subnet_mask] 

show ip protocols [summary] 

show ip route 

debug eigrp packets 

eigrp log-neighbor-changes 


show ip eigrp neighbors Command 


This can be one of the most useful commands when verifying the operational status of EIGRP. The 
show ip eigrp neighbors command shows the status of all EIGRP neighbors. The neighbor should be 
"up" for as long as EIGRP has been running on the link. EIGRP forms a neighbor relationship with all 
routers on the same subnet and in the same AS. EIGRP does not form a neighbor relationship with 
mismatched k values; however, a neighbor can be formed with mismatched hellos and dead timers. A 
neighbor with a short uptime is a clear indication of a problem. Another important field is the queue 
count. This field indicates the number of packets waiting to be transmitted to that neighbor. This value 
should be 0 or a number under 20. Consistent Q values in the range of 60 or greater are considered 
high. A high SRTT number can mean that the packet is experiencing some type of delay on the link. 
Example 11-8 provides some sample output from the show ip eigrp neighbor command, which 


provides the basis for an explanation of the other fields, which follows. 


Example 11-8 show ip eigrp neighbor Command Performed on the grinch 
Router 


grinch#show ip eigrp neighbors 
IP-EIGRP neighbors for process 2001 


H Address Interface Hold Uptime SRIT RTO Q Seq 

(sec) (ms) Cnt Num 
1 V2 565135 Se0.1 136 05:48:23 36 1302 0 15 
0 1723.16.16 Se0.1 131 05:48:24 40 1302 0 17 
grinch# 


e Handle (H)—A Cisco 1OS internal number used to identify a neighbor. Do not confuse this with 
hop count. 


e Neighbor Address— The adjacent neighbor's IP address. A neighbor should be formed between 
every router on that subnet running EIGRP in a common AS. 


e Interface— The interface that is reporting the neighbor. 


e HoldTime— The amount of time, which counts down, that EIGRP waits for a hello before tearing 
down the neighbor. 
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e Uptime— Statement of how long the neighbor has been up. This number should be up for as 
long as the link has been up. 


e Smooth Round Trip Timer (SRRT)— The number of milliseconds that it takes for an EIGRP 
packet to be sent to this neighbor and for the local router to receive an acknowledgment— 
hence, a round-trip timer. If this number equals 0, a packet has never made a successful round 
trip. 


e Retransmission TimeOut (RTO)— The amount of time, in milliseconds, that the ElGRP waits 
before retransmitting a packet from the retransmission queue to a neighbor. 


e Queue count (Q)— The number of packets waiting in the queue to be sent out to this neighbor. 
This value should be O or a very low number. A high queue count indicates that data is having 
trouble getting through. 


e Sequence Number (Seq-Num)— Sequence number of the last update, query, or reply that 
was received from this neighbor. If this number equals 0, it indicates that no reliable packets 
have ever been received from the neighbor, another clear indication of a problem. 


NOTE 


Just because a network appears in the route table does not necessarily mean that "routing" 
is working properly. In some instances, such as timer mismatches, networks can "phase" 
in and out of the route table. It is important to look at other things, such as neighbors and 
databases, to get a clearer view of whether "routing" is actually working properly. 


show ip eigrp topology Command 


This command lists the EIGRP topology table discussed earlier. The table lists all routes that EIGRP is 
aware of and shows whether EIGRP is actively processing information on that route. Under most normal 
conditions, the routes should all be in a passive state and no EIGRP process are running for that route. 
If the routes are active, this could indicate the dreaded stuck in active, or SIA, state, which is discussed 
in more detail in an upcoming section. The show ip eigrp topology command also can be extended to 
show information about an individual route or subnet. This information includes all relevant information 
about the route, including all its metrics and successors, as well as how the route was learned. Example 


11-9 illustrates the use of show ip eigrp topology, followed by the extended version of the command. 


Example 11-9 EI GRP Topology Table of the grinch Router 


grinch#show ip eigrp topology 
IP-EIGRP Topology Table for process 2001 


Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, 
r — Reply status 


P 172.16.5.0/24, 1 successors, FD is 23394560 
via 172.16.1.5 (23394560/281600), Serial0.1 
P 172.16.6.0/24, 1 successors, FD is 23394560 
via 172.16.1.6 (23394560/281600), Serial0.1 
P 172.16.1.0/24, 1 successors, FD is 23368960 
via Connected, Serial0O.1 
P 172.16.2.0/24, 1 successors, FD is 281600 
via Connected, Ethernetl 


grinch# 


grinch#show ip eigrp topology 2001 172.16.5.0 255.255.255.0 
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IP-EIGRP topology entry for 172.16.5.0/24 

State is Passive, Query origin flag is 1, 1 Successor(s), FD is 23394560 

Routing Descriptor Blocks: 

L72.16.1.5 (Serialo.1), from 172.16.1.5, Send flag is: 0x0 
Composite metric is (23394560/281600), Route is Internal 
Vector metric: 

Minimum bandwidth is 112 Kbit 
Total delay is 21000 microseconds 
Reliability is 254/255 
Load is 1/255 
Minimum MTU is 1500 
Hop count is 1 

grinch# 


The fields to note in this output are as follows: 
e P— Passive; no EIGRP computation is being performed. This is the ideal state. 


e A— Active; EIGRP computations are "actively" being performed for this destination. Routes 
constantly appearing in an active state indicate a neighbor or query problem. Both are 
symptoms of the SIA problem. 


e U— Update; an update packet was sent to this destination. 
e Q— Query; a query packet was sent to this destination. 
e R— Reply; a reply packet was sent to this destination. 


e Route information— |P address of the route or network, its subnet mask, and the successor, 
or next hop to that network, or the feasible successor. 


e FD— Feasible distance to the destination network. 
e Send Flag— The type of packets that need to be sent for the entry. 
- 0x1 The router has received a query for this network and needs to send a unicast reply. 
- 0x2 The route is active, and a multicast query should be sent. 
- 0x3 The route has changed, and a multicast update should be sent. 
show ip protocols Command 


This command displays all routing protocols, detailed timer and metric information, as well as routing 
update information. Example 11-10 lists the output of the show ip protocols command. 


Example 11-10 show ip protocols Command Output 


grinch#show ip protocols 
_ 


Outgoing update filter list for all interfaces is 
Incoming update filter list for all interfaces is 
Default networks flagged in outgoing updates 
Default networks accepted from incoming updates 


_ 
ER Sg Se Wea Ben aie eat aes 
esata 683 


EIGRP maximum hopcount 100 
EIGRP maximum metric variance 1 
Redistributing: eigrp 2001 


~auto-summary in effect 
Routing for Networks: 
“Networks running EIGRP 
Routing Information Sources: 
Gateway Distance Last Update 
_ 
1726.46.16 20 00308352 distance of the route. 
Distance: internal 90 external 170 Default admin distance 
grinch# 


show ip route Command 


This command lists the router's current route or forwarding table. The output lists what routing protocol 
the route is from—in this case, D for EIGRP internal routes and D EX for routes redistributed into EIGRP. 
The number behind the route is the administrative distance of the route, followed by the composite 
metric of the route. The via field explains where the route is from, how long ago an update was 
received, and by what interface it was received. Example 11-11 lists the output of this command. 


Example 11-11 show ip route Command Output 


grinch#show ip route 
Codes: C -— connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 
D — EIGRP, EX -— EIGRP external, O - OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
BK1 —- OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U - per-user static route, o — ODR 


Gateway of last resort is not set 


172.16.0.0/24 is subnetted, 4 subnets 


D 172.16.5.0 [90/23394560] via 172.16.1.5, 00:17:51, Seriald.1 
D 172.16.6.0 [90/23394560] via 172.16.1.6, 00:29:06, Seriald.1 
Cc 172.16.1.0 is directly connected, Serial0d.1 

C 172.16.2.0 is directly connected, Ethernetl 

grinch# 


debug eigrp packets Command 


The "Big D" command for EIGRP, is just that: big. As discussed earlier, debugs always should be used in 
conjunction with logging. However, some EIGRP debugs can be so big that additional debugs are 
needed to control the output of the original debug command. One such case is the debug eigrp 
packets command. 


Use the debug eigrp packets command to verify that EIGRP hellos are being exchanged and that 
adjacencies are being established. Each EIGRP packet sent and received is listed in this output. The 
output of this command can be controlled with further debugs, such as debug ip eigrp [neighbor 
as_number !P_address_of_neighbor]. Use the debug ip eigrp command. Use this command with 
caution and only to look further into a problem. Do not start troubleshooting EIGRP with this command. 
Example 11-12 lists the output of the debug eigrp packets command. 


Example 11-12 debug eigrp packets Command Output 
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grinch#debug eigrp packets 

06:22:29: EIGRP: Received HELLO on SerialO.1 nbr 172.16.1.5 

06222329: AS 2001, Flags 0x0, Seq 0/0 idbQ 0/0 

06:22:29: EIGRP: Enqueueing UPDATE on Serial0O.1 nbr 172.16.1.5 iidbQ un/rely 0/1 
peerQ un/rely 0/0 serno 2-10 

06:22:29: EIGRP: Requeued unicast on Serial0O.1 

06:22:29: EIGRP: Sending UPDATE on Serial0.1 nbr 172.16.1.5 

062222529: AS 2001, Flags 0xl, Seq 7/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 
0/1 serno 2-10 


eigrp log-neighbor-changes Command 


EIGRP also offers a unique logging command that can be useful when trying to isolate problems on your 
network. Use the router command eigrp log-neighbor-changes to verify any loss of EIGRP neighbors. 
Example 11-13 lists the log after an EIGRP hold time has expired. 


Example 11-13 EIGRP Log After a Neighbor Change 


grinch (config-router) feigrp log-neighbor-—changes 
06:42:12: SDUAL-5-NBRCHANGE: IP-EIGRP 2001: Neighbor 172.16.1.6 (Serial0O.1) isd 
own: holding time expired 


685 


Tuning EIGRP Updates 


Like IGRP, EIGRP has several parameters for tuning timers, controlling broadcasts, load 
sharing, and controlling routes. The following is a list of parameters adjustable for El GRP: 


Router(config-if)ip hello-interval eigrp as_ number interval_in_seconds— Use this 
interface command to change the hello timer for EIGRP. The default value of this 
command is interface-dependant. By default, hello packets are sent every 5 seconds. 
The exception to this is low-speed, nonbroadcast multiaccess media (NBMA), where it 
is 60 seconds. Low-speed is defined as rates of T1 (1.544 Mbps) or slower. All 
neighbors residing on a network should have equal hello timers. 


Router(config-if)ip hold-time eigrp as_number holdown_timer_in_seconds— Use 
this command to change the EIGRP hold timer for routes received by this interface. 
The timer has a default vault of 180 seconds for low-speed NBMA networks and 15 
seconds for all other networks. All neighbors residing on a network should have an 
equal hold timer. 
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EIGRP Redistribution and Route Control 


To filter routing updates in EIGRP, use a distribute list. A distribute list calls a standard or 
extended access list and filters routing updates accordingly. When redistributing one protocol 
into another, use the redistribute command along with a default metric. A route map should 
be used in place of a distribute list when controlling specific routes during the redistribution 
process. Redistribution happens automatically between IGRP and EIGRP when they are in the 
same autonomous systems. 


e Router(config-router) distribute-list [1-199] [in | out] [interface]— Use this 
command to call a standard or extended access list to filter inbound or outbound 
routing updates. The in and out options always are applied from the view of the 
interface—in other words, to prevent a routing update from being advertised out an 
interface, use the out option. To prohibit route updates from entering an interface, 
use the in option. 


e Router(config-router) redistribute [connected | static | bgp | rip | igrp | ospf | 
isis] {metric} {route-map}— Use this command to redistribute other routing 
protocols into EIGRP. A route map may be added for additional route control. An 
optional metric also can be supplied for routes originating from the routing protocol 
being redistributed that are different from the default metric. Whenever redistributing 
routes, remember that IP needs a route to and from a destination. Many times, 
mutual redistribution might be required to give IP a path to and from a destination. 


Router(config- router) default-metric [bandwidth_kbps 1-4214748364] [delay_ ms 1- 
4214748364] [reliability 1-255] [load 1-244] [mtu 1-4214748364]— Use this 
command to set the default metric of all routes redistributed into EIGRP. You must 
supply a default metric whenever redistributing. A common metric to use is default- 
metric 1544 100 254 1 1500. This metric tells the router to derive the composite 
metric from the values of bandwidth of 1544 and delay of 100; with a link that is 254 
reliable, where 255 is 100 percent reliable; with a load of 1, or no load; and, finally, 
an MTU of 1500. Perhaps more important than the actual value of the default metric is 
the practice of using the same metric throughout the EIGRP domain so that all 
redistributed routes have the same weight. 


NOTE 


Whenever you are redistributing one routing protocol into another, you must use 
a default metric or supply a metric on the redistribution command. 


The following subsets of commands are used to influence routing decisions made by EIGRP. 
Individual metrics can be modified in addition to the administrative distance of the EIGRP. 
Whenever you are influencing a specific link's metric, use the delay command over the 
bandwidth command. Both may be used; however, recall that OSPF also is affected by 
bandwidth, whereas delay affects only |GRP and EIGRP. 


e Router(config-router)metric weights O k1 k2 k3 k4 k5— This command allows you 
to set the weight of the EIGRP metric in terms of bandwidth, load, delay, and 
reliability. Change these values with extreme caution; EIGRP will not form neighbors 
with mismatched K values. 
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Router(config-router) distance [1-255] adjacent_neighbors_ip address wildcard_ 
mask [access_list_0-99]— Use this command to change the administrative distance of 
routes received from a neighbor. If the |P address and wildcard mask are omitted, all 
routes for that protocol will be set to the distance value. 


Router( config-if) delay [1-4214748364]— Specifies the delay of an interface in tens 
of microseconds. This command is used only by routing protocols and does not affect 
traffic on the link. 


Router(config-if) bandwidth [bandwidth_kbps 1-4214748364]— Specifies the 
bandwidth of an interface in kilobits per second. This command is used only by 
routing protocols and does not affect traffic on the link. 


Router(config-router) passive-interfaceinterface_name— Prevents the sending of 
EIGRP hellos on the link. This command operates differently on EIGRP than on |GRP. 
Because hellos are suppressed, no neighbors are formed; therefore, no routing 
updates are sent or received. 


Router(config-router) offset-list [access_list_0-99 {in | out} offset 
[metric_offset_ 1-214748364] [interface]— Used to increase the value of the routing 
metrics. The metric offset cannot exceed 214748364. The offset list is applied in the 
same way as it is in RIP, using the EIGRP metric. For an example of the application of 
the offset list, see Chapter 9, "Distance Vector Protocols: Routing Information Protocol 
Versions 1 and 2 (RIP-1 and RIP-2). 


Practical Example: Applying EIGRP Redistribution 


Let's apply some of these concepts to a practical model in route redistribution and control. 
The model in Figure 11-6 shows three routing domains. The canada routers and the Frame 
Relay network reside in the EIGRP domain. Across the Frame Relay network reside two other 
routing domains; the mexico routers are in an |GRP domain, while the usa routers reside in 
an OSPF domain. 


Figure 11-6. EI1GRP Network For EIGRP Redistribution and Route 


Control Examples 
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You must verify two things within the routing domains to allow IP end-to-end connectivity: 


e Notice that the |GRP domain is on a 24-bit boundary. This means that when the IGRP 
domain receives a route, it must exist on a major bit boundary or a 24-bit boundary 
for the interface to accept that route. 

e Mutual redistribution must occur between EIGRP and IGRP, and EIGRP and OSPF. 


Beginning with the configuration for the canada_1 router, you can follow the three-step 
process for configuring EIGRP as listed earlier in this chapter. First, all E1GRP routers are in 
the autonomous system 2001; therefore, you will use this as the Autonomous System ID. 
Second, the networks that you are running EIGRP on reside in the major network of 
172.16.0.0, which you will use in the network command. The third step is optional; in this 
case, however, you are configuring EIGRP over Frame Relay, so it's a good idea to add the 
bandwidth commands under the serial subinterfaces. In this model, you will set the 
bandwidth equal to the port speed of the remote routers Frame Relay interface. Example 11- 


14 lists the configuration of the canada_1 router. 


Example 11-14 Configuration of the canada_1 Router 


hostname canada_1l 

! 

interface Serial0 

no ip address 

encapsulation frame-relay 
no ip mroute-cache 

! 

interface Serial0.1 point-to-point 
ip address 172.16.1.1 255.255.255.0 


bandwidth 64 === = BIGRP bandwidth set 
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frame-relay interface-dlci 110 

! 

interface Serial0.2 point-to-point 
ip address 172.16.2.1 255.255.255.0 


toe 


frame-relay interface-dlci 130 
! 
interface TokenRingO 

ip address 172.16.3.1 255.255.255.0 

ring-speed 16 
! 


ESB Parioade pases 

router eigrp 2001 = = ==)“ EIGRP_ routing enabled 

“Networks running EIGRP 
You can follow the same process to configure EIGRP for the mexico_1 and usa_1 routers, 
with a couple of minor differences. In both instances, you do not want to risk having any 
EIGRP neighbors automatically created on the Ethernet segments of these routers. To 
accomplish this, add the passive-interface ethernet 0 command under EIGRP for the 
mexico_1 and usa_1 routers. Example 11-15 lists the configuration thus far for the mexico_1 


and usa_1 routers. For more information on the IGRP and OSPF configuration portions of the 
configuration, see Chapter 12, "Link-State Protocols: Open Shortest Path First (OSPF)." 


Example 11-15 EI GRP Configuration of mexico_1 and usa_1 Routers 


hostname mexico_1 
! 
interface Ethernet0O 
ip address. 172.16.5.5 255.255.255.0 
no ip directed-broadcast 
! 
interface Serial0O 
no ip address 
no ip directed-broadcast 
encapsulation frame-relay 
no ip mroute-cache 
! 
interface Serial0O.1 point-to-point 
ip address 172.16.1.5 255.255.2550 
no ip directed-broadcast 
frame-relay interface-dlci 111 
! 
<<<Text omitted>>> 
! 
router eigrp 2001 
passive-interface Ethernet0 
network 172.16.0.0 
! 
router igrp 2000 
passive-interface Serial0.1 
network 172.16.0.0 
<<<Text omitted>>> 


hostname usa_l 
1 
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interface Ethernet0O 

ip address: 172. 16.6.6 255.255.4255..'0 
! 
interface Serial0 

no ip address 

encapsulation frame-relay 

' 
interface Serial0O.1 point-to-point 
ip eddress. 172.16.2.6 255.255..255..0 
frame-relay interface-dlci 131 

! 


<<<Text omitted>>> 

\ 

router eigrp 2001 
passive-interface Ethernet0O 
network 172.16.0.0 

\ 

router ospf 69 

network 172.16.6.6 0.0.0.0 area 0 
<<<Text omitted>>> 


At this point, you should have full IP connectivity within the EIGRP routing domain. To verify 
this, perform a show ip route combined with the show ip eigrp neighbors command on 
the canada_1 router, as demonstrated in Example 11-16. 


Example 11-16 Verifying EIGRP Routing 


canada_l#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M —- mobile, B - BGP 
D —- EIGRP, EX - EIGRP external, O - OSPF, IA —- OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U - per-user static route, o — ODR 


Gateway of last resort is not set 


172.16.0.0/24 is subnetted, 5 subnets 


D 172.16.5.0 [90/40537600] via 172.16.1.5, 00:45:58, Serial0.1 
D 172.16.6.0 [90/40537600] via 172.16.2.6, 00:45:58, Serial0.2 
Cc 172.16.1.0 is directly connected, Serial0O.1 

GC 172.16.2.0 is directly connected, Serial0.2 

Cc 172.16.3.0 is directly connected, TokenRing0O 

D 182.16.0.0/16 [90/304128] via 172.16.3.3, 00:43:27, TokenRingO 


canada_1l# 
canada_l#show ip eigrp neighbors 
IP-EIGRP neighbors for process 2001 


H Address Interface Hold Uptime SRTT RTO Q Seq 
(sec) (ms) Cnt Num 

2 VIZ 2D66 303 To0 11 00743336 685 4110 0 3 

1 1726.16.26 Se0.2 14 1d06h 48 2280 0 28 

0 172216 515.5 Se0.1 12 1d06h 29 2280 0 23 


canada_1l# 


The important elements of the output that you are looking for are that route 172.16.5.0/24 is 
reported through 172.16.1.5, route 172.16.6.0/24 is reported through 172.16.2.6, and 
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182.16.3.0/24 and 182.16.4.0/24 are reported through 172.16.3.3. Because of EIGRP 
autosummarization, 182.16.3.0/24 and 182.16.4.0 will be summarized at its natural 16 bit- 
boundary when these routes are advertised out the canada_2 Token Ring interface. The 
show ip eigrp neighbors command verifies that El1GRP adjacencies have been formed 
between canada_1 and the other two routers. 


To allow EIGRP connectivity to the OSPF routing domain, you must mutually redistribute 
between EIGRP and OSPF on the usa_1 router. There is only one redistribution point for 
EIGRP and OSPF, so you do not have to take into account "route feedback" or redistribution 
loops. Example 11-17 shows the configuration of the usa_1 router. 


Example 11-17 Redistribution Configuration Portion of usa_1 


! 


router eigrp 2001 

redistribute ospf 69 
passive-interface Ethernet0O 
network 172.16.0.0 

default-metric 1544 100 254 1 1500 
\ 

router ospf 69 

redistribute eigrp 2001 subnets 
network 172.16.6.6 0.0.0.0 area 0 


default-metric 100 
1 


The OSPF routes 192.168.3.0/24 and 192.168.4.0/24 now appear as external EIGRP routes 
on the canada_1 router. Likewise, all E1\GRP routes appear as OSPF external Type 2 routes on 
the usa_2 router. 


Mutual redistribution also must be performed between the EIGRP and IGRP routing domains 
on the mexico_1 router. If the IGRP routing domain was in the same autonomous system as 
EIGRP, redistribution would not be necessary because it would occur automatically. Example 


11-18 shows the configuration of the mexico_1 router. 


Example 11-18 Redistribution Configuration portion of mexico 1 


' 


router eigrp 2001 

redistribute igrp 2000 
passive-interface Ethernet0O 
network 172.16.0.0 

default-metric 1544 100 254 1 1500 
1 

router igrp 2000 

redistribute eigrp 2001 
passive-interface Serial0O.1 
network 172.16.0.0 


default-metric 1544 100 254 1 1500 
i} 


The route table for the mexico_2 router now shows all the appropriate routes for every 
network in the model. Example 11-19 shows the route table of mexico_2. 
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Example 11-19 Route Table of the mexico_2 Router After 
Redistribution 


mexico_2#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M —- mobile, B - BGP 
D —- EIGRP, EX —- EIGRP external, O - OSPF, IA —- OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
Bl - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U —- per-user static route, o —- ODR 


Gateway of last resort is not set 


172.16.0.0/24 is subnetted, 5 subnets 


Cc 172.16.5.0 is directly connected, Ethernet0/0 

af 172.16.6.0 [100/10676] via 172.16.5.5, 00:00:16, Ethernet0/0 
an 172..16.1.0° [1100/8576] via 172.16.5.5, O0:00:16, Ethernet 0/0 

I W72516.2<0 [100/10576] via 172.16.5.5, 00700316, Bthernet0/0 
I 172.16.3.0 [100/8639] via 172.16.5.5, 00:00:16, Ethernet0/0 

I 192.168.4.0/24 [100/10676] via 172.16.5.5, 00:00:16, Ethernet0/0 
I 182.16.0.0/16 [100/9139] via 172.16.5.5, 00:00:16, Ethernet0/0 

I 192.168.3.0/24 [100/10676] via 172.16.5.5, 00:00:16, Ethernet0/0 


mexico_2# 


The redistribution in this model was relatively straightforward because all the networks in the 
model either are on a 24-bit boundary or are automatically summarized on a 24-bit 
boundary. EIGRP automatically summarizes at a major bit boundary when advertising or 
redistributing. During redistribution into |GRP, EIGRP automatically summarized the network 
192.168.4.0/24 because it is on a 24-bit boundary along with 192.168.3.0/24. The network 
182.16.0.0 was summarized when it was advertised out the sO.1 and sO.2 interfaces. 


It is important to note that if the IP address of the advertising interface is in the same major 
class boundary as the route being advertised, automatic summarization will not occur. For 
example, if the router were advertising 172.16.100.0/30 out an interface with an IP address 
of 172.16.10.1/24, EIGRP would not summarize the route at its natural bit boundary. If the 
same network, 172.16.100.0/24, was advertised out an interface with the IP address of 
172.17.10.1/24, EIGRP would advertise only the summary route 172.16.0.0/16, as seen in 
the previous model. 


As you will see in the upcoming section on EIGRP summarization, we will make some subtle 
changes to the IP address structure, which will force the use of manual summarization before 
redistribution will work correctly. 


Practical Example: Applying EIGRP Route Control 


Now that you have a working IP network, let's examine route control through the application 
of route maps and distribution lists using the network in Figure 11-6 as the model again. On 
the usa_1 router, you will apply a distribution list preventing the route 192.168.3.0/24 from 
being advertised by EIGRP to the entire EIGRP domain. To carry out this task, use the 
distribute-list router command; apply an access list denying 192.168.3.0/24, while allowing 
other routes to be advertised. Example 11-20 highlights the configuration of the usa_1 
router, allowing EIGRP to advertise only the 192.168.3.0/24 route. 
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Example 11-20 Application of Distribution List 


router eigrp 2001 

redistribute ospf 69 
passive-interface Ethernet0O 
network 172.16.0.0 

default-metric 1544 100 254 1 1500 


distribute-list 10 out Serial0.1 © ‘apply access list 10 to interface s0.1 
! 


router ospf 69 

redistribute eigrp 2001 subnets 
network 172.16.6.6 0.0.0.0 area 0 
default-metric 100 

1 


ip classless 

access-list 10 deny 192.168.3.0 0.0.0.255 “deny route 192.168.3.0/24 
access-list 10 permit any = “allow all other routes to pass 

! 


Whenever you are controlling routing updates from one routing protocol to another, use a 
route map. In this model, a route map is used to prohibit the OSPF route of 172.16.6.0/24 
from being redistributed from EIGRP into |GRP. The route map is called from the 
redistribution command in |GRP; the route map then calls and permits routes that match 
access list 11. Example 11-21 lists the configuration of the mexico_1 router using a route 


map to filter the route 172.16.6.0/24. 


Example 11-21 Calling a Route Map During Redistribution on 
mexico_1 


router eigrp 2001 

redistribute igrp 2000 
passive-interface Ethernet0O 
network 172.16.0.0 

default-metric 1544 100 254 1 1500 
i} 


router igrp 2000 


*~ call route map named noospf 
passive-interface Serial0.1 
network 172.16.0.0 
default-metric 1544 100 254 1 1500 
! 
ip classless 
! 
“deny 172.16.6.0/24 


access-list 11 permit any 
route-map noospf permit 10 


match ip address 11 = * allow routes that pass access list 11 


The route table on the mexico_2 router now shows only one route from the OSPF domain 
192.168.4.0. Compare the output in Example 11-22 with that of Example 11-19 to vis 


application of the route map and distribution list. 


Example 11-22 The Route Table of mexico_2 After Route Filtering 


mexico_2#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M —- mobile, B - BGP 
D —- EIGRP, EX -—- EIGRP external, O - OSPF, IA —- OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U - per-user static route, o — ODR 


Gateway of last resort is not set 


172.16.0.0/24 is subnetted, 4 subnets 
172.16.5.0 is directly connected, Ethernet0/0 
172.16.1.0 [100/8576] via 172.16.5.5; 00:00:51, Ethernet 0/0 
172.16.2.0 [100/10576] via 172.16.5.5, 00:00:51, Ethernet0/0 
172..16.3.0 [1007/8639] via 172.16.5.5, 00s00:51, Bthernet0/0 
192.168.4.0/24 [100/10676] via 172.16.5.5, 00:00:51, Ethernet0/0 
182.16.0.0/16 [1000/9139] via 172:.16:5:.5, 00:00:51, EBthernet0/0 
mexico_2# 


HHHHHA 


NOTE 


A route map also may be used to set an EIGRP tag, using the syntax set tag xx 
under the route-map command. Setting tags can be useful for looking at how 
routes entered a route table. The tag can be viewed in EIGRP by the show ip 
eigrp topology command, and in OSPF by show ip ospf database. The OSPF 
tag also can be entered directly on the redistribution command. 
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EIGRP Summarization 


Understanding EIGRP summarization and knowing how to effectively use it are absolutely vital to 
the design of large EIGRP networks. EIGRP scales very well, but when the number of routes starts 
to climb into the hundreds, extra care should be taken to control route propagation and the query 
range. AS much as EIGRP is plug-and-play on small networks, it is not on large networks. The 
larger the network is, the more care should be taken to control how routes propagation. 


Summarization provides two powerful enhancements to EIGRP. First, by lowering the number of 
routes in the route table, it lessens the number and size of the EIGRP advertisements. Second, and 
more importantly, it can limit the EIGRP query range. 


Controlling the Query Range Through Summarization, Addressing Stuck in 
Active (SIA) Route Issues 


Arguably one of the most common and complex problems facing large EIGRP networks is stuck in 
active (SIA) routes. A route becomes SIA when EIGRP is "actively" running computations for the 
route, and it doesn't stop. EIGRP will log multiple messages similar to the following: 


SDUAL-—3-SIA: Route 192.168.1.16 Stuck-—in-Active 


Most of the time, the route shows active because it is waiting for query to return from neighbor. 
There can be many reasons for this: 


e The router is overutilized— Edge routes can get flooded with query request and often 
don't have the CPU power to keep up with the request. Queries receive irregular replies, if 
any, and the route stays active. 


e The router is having memory issues— This can be compounded from a slow processor 
and the router having many items in its queues. 


e Overutilized circuit— EIGRP hellos might not be getting through, causing the neighbor to 
drop. 


Two types of configurations can manifest the SIA situation: 


e Most EIGRP networks have autosummary disabled. This is primarily because the IP 
addressing scheme has discontinuous subnets, so the query range is not bounded. 

e Large Frame Relay networks have many remote sites coming into the same router, 
therefore, there are many EIGRP neighbors. 


For example, in a Frame Relay network, if a single PVC goes inactive or a route starts flapping, it 
can cause a small EIGRP query storm. Figures 11-7 and 11-8 illustrate a common Frame Relay 


network and the query process. 


Figure 11-7. E1GRP Network 


696 


If the PVC is lost from canada_1 to mexico_1, the canada_1 router sends an EIGRP query message 

to all of its neighbors regarding the routes that it lost from the mexico_1 router. It is looking for a 

new feasible successor to the routes. In this case, the message goes to the swiss_1 and usa_1 

routers. The mexico_1 router also sends a query message to all of its neighbors looking for a new 

feasible successor for the routes that it lost from canada_1. All routers in the EIGRP domain 

continue to issue queries to neighbors. The routes stay in an "active" state until El1GRP receives 
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"replys" to the queries that it sent. If you scale this network to a router with an HSSI or T3 
interface, it would be possible to have hundreds of PVCs on a single interface, and the loss of just a 
single PVC could generate hundreds or thousands of queries. Fortunately, summarization bounds 
the query process and is one of the most effective ways to control EIGRP query storms. A large 
EIGRP network without summarization is an SIA problem looking for an owner. 


EIGRP Autosummarization 


By default, EIGRP performs autosummarization in two situations: 


e Autosummarization will occur at the major class boundary during redistribution from ElGRP 
into a classful routing protocol, such as IGRP or RIP. This type of summarization cannot be 
disabled. 

e Autosummarization will occur at the major class boundary when the route is advertised out 
an interface that is on a different major class boundary. This summarization can be disabled 
with the command no auto-summary from the router(config-router) prompt. 


EIGRP will not automatically summarize ElGRP external routes. 


EIGRP routes that are summarized have an administrative distance of 90. In Figure 11-9, the 


internetwork has been modified from the previous example, adding two additional networks to the 
canada_2 router. 


Figure 11-9. EI1GRP Autosummarization 


ToP-172 16 3 4 
So2 


Peth2 62104 


50.1 pore pore 
Pot72 16.10.0264 


EIGRP EIGRP 


AS 2001 


IGRP AS 
OSPF 
= domain 
menco_1 : 
Eo 
Put72 16.0.024 
eo Patt? 61594 
Pa 17Z1GS SM 
£0 
mexico_2 (Pot72 145.826 


With autosummarization enabled, EIGRP on the canada_2 router advertises two summary routes to 
canada_1. The routes 182.16.3.0/24 and 182.16.4.0/24 are advertised as 182.16.0.0/16. The 
routes 10.1.1.0/24 and 10.1.2.0/30 are advertised at their natural class boundary with a route of 
10.0.0.0/8. It is important to note that EIGRP summarizes the route only when advertising out an 
interface that is in a different class. For example, if the network between canada_1 and canada_2 
is 10.1.3.0/24, the 10's network would not be summarized; only the 182.16.x.x networks would. 
Example 11-23 lists the route table of canada_1, highlighting the summarized routes. 
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Example 11-23 Route Table of canada_1 with Summarized Routes 


canada_l#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 
D — EIGRP, EX — EIGRP external, O — OSPF, IA - OSPF inter area 
Nl - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U -— per-user static route, o — ODR 
Gateway of last resort is not set 


172.16.0.0/24 is subnetted, 5 subnets 


D 172.16.5.0 [90/2195456] via 172.16.1.5, 01:06:41, Seriald.1 
D 172.16.6.0 [90/2195456] vie 172.16.2.6, 01208501, Serial0.2 
Cc 172.16.1.0 is directly connected, Serial0.1 
Cc 172.16.2.0 is directly connected, Serial0.2 
Cc 172.16.3.0 is directly connected, TokenRing0O 
192.168.4.0/32 is subnetted, 1 subnets 
D EX 192.168.4.1 [170/2195456] via 172.16.2.6, 01:07:46, Serial0.2 


192.168.3.0/32 is subnetted, 1 subnets 
D EX 192.168.3.1 [170/2195456] via 172.16.2.6, 01:07:46, Seriald.2 
canada_l# 


As helpful as EIGRP summarization might appear on the surface, it has serious drawbacks on most 
modern networks. It essentially makes a classless routing protocol enforce the discontinuous 
subnets rule at the major bit boundaries. When EIGRP forms a summary route to advertise, it also 
forms a route to null for all the networks in that summary. For example, the canada_2 router will 
form three routes to null for each major class network that the router has an interface in. The 
route to null will discard any packets that this router does not have an explicit route to. Example 


11-24 demonstrates autosummary null routes displayed by the show ip route command. 


Example 11-24 EIGRP Autosummary Null Routes 


canada_2#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 
D — EIGRP, EX — EIGRP external, O —- OSPF, IA - OSPF inter area 
Nl - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U -— per-user static route, o — ODR 


Gateway of last resort is not set 


172.16.0.0/16 is variably subnetted, 6 subnets, 2 masks 


D 172.16.5.0/24 [90/2211584] via 172.16.3.1, 00:12:02, TokenRing0O 
D 172.16.6.0/24 [90/2211584] via 172.16.3.1, 00:12:02, TokenRing0O 
D 172:.16.0.0716 asa. summary, 00212306, Nullo 
D 172.16.1.0/24 [90/2185984] via 172.16.3.1, 00:12:02, TokenRing0O 
D 172.16.2.0/24 [90/2185984] via 172.16.3.1, 00:12:02, TokenRing0O 
Cc 172.16.3.0/24 is directly connected, TokenRing0O 

192.168.4.0/32 is subnetted, 1 subnets 
D EX 192.168.4.1 [170/2211584] via 172.16.3.1, 00:12:02, TokenRing0Od 


10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks 
10.1.2.0/30 is directly connected, Loopback32 


[e) 


@ 


10.1.1.0/24 is directly connected, Loopback31 699 


182.16.0.0/16 is variably subnetted, 3 subnets, 2 masks 
Cc 182.16.4.0/24 is directly connected, Loopback21 
Cc 182.16.3.0/24 is directly connected, Loopback20 


192.168.3.0/32 is subnetted, 1 subnets 
D EX 1923168:..3.1 [T70/2211584] via 172.16.3.1, 00:12:03, TokenRingd 
canada_2# 


e For autosummarization to work properly, discontiguous subnets at the major bit boundaries 
must be avoided at all costs. Unfortunately, on modern networks, something causes 
subnets to be deployed in places they shouldn't be, and EIGRP has forwarding problems. By 
disabling autosummarization with the no auto-summary command, the routes to null are 
not created and automatic summary routes are not forwarded. In place of autosummary, 
use manual summarization. Most engineers that we have worked with disable 
autosummarization when using EIGRP to prevent routes to the null interface. 


EIGRP Manual Summarization or Route Aggregation 


EIGRP manual summarization is critical to large EIGRP networks. It limits the EIGRP query and can 
significantly reduce the size of the routing table. There are essentially two ways to deploy manual 
summarization: 


e Advertise an summary address or aggregate address with the following interface command: 
ip summary-address eigrp as_number summary_address address_mask 
e Advertise a default route with the following interface command: 


ip summary-address eigrp as_number 0.0.0.0 0.0.0.0. 


This command causes only the default route to be advertised; all other routing updates are 
suppressed. 


One of the powerful functions of EIGRP is the capability to advertised multiple summary routes and 
default routes on different interfaces. The EIGRP network in Figure 11-10 is under the same 
autonomous system, and autosummary has been disabled on all the routers. In this model, ElGRP 
is configured to advertise a default route out the s0.2 port on the canada_1 router to the usa_1 
router. The canada_1 router also advertises two summary routes, 182.0.0.0/8 and 10.0.0.0/8, out 
the sO.1 interface to the mexico_1 router. 


Figure 11-10. E1GRP Manual Summarization 
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Example 11-25 lists the configuration of canada_1 router performing manual summarization. 


Example 11-25 Manual Summarization on canada_ 1 Serial Interfaces 


interface Serial0d 
no ip address 
encapsulation frame-relay 


no ip mroute-cache 


interface Serial0.1 point-to-point 
ip address 172.16.1.1 255.255;255..0 
Lp aeumnar y Sadaressvelgep e200 Nez Ome Zooey Manualssummenizertoy 


frame-relay interface-dlci 110 


! 
interface Serial0.2 point-to-point 


ap address 172416.2.1 255.255.2550 


frame-relay interface-dlci 130 


! 
interface TokenRing0O 
ip address 172.16.3.1 255.255.2550 
ring-speed 16 
! 
router eigrp 2001 
network 172.16.0.0 
no auto-summary 
! 
Example 11-26 lists the route table of the mexico_1 router and the usa_1 router. Notice how the 
routes are summarized. The usa_1 router receives only a default route 0.0.0.0, and the gateway of 


last resort is set. 
Example 11-26 Route Tables of mexico_1 and usa_1 with Summarization 


Applied 


mexico_l#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M —- mobile, B - BGP 
D — EIGRP, EX — EIGRP external, O — OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * -— candidate default 
U - per-user static route, o —- ODR 
T - traffic engineered route 


Gateway of last resort is not set 


172.16.0.0/24 is subnetted, 5 subnets 
¢ 172.16.5.0 is directly connected, Ethernet0 
D 172.16.6.0 [90/2707456] via 172.16.1.1, 00:34:11, Seriald.1 
Cc 172.16.1.0 is directly connected, Serial0.1 
D 172.16.2.0 [90/2681856] via 172.16.1.1, 00:34:11, Serial0O.1 
D 172.16.3.0 [90/2185984] vie 172.16:1.1, 00:34:11, Serialo.21 
D 192.168.4.0/24 [90/2835456] via 172.16.1.1, 00:34:11, Serial0.1 
10.0.0.0/8 [90/2313984] via 172.16.1.1, 00:34:11, Seriald.1 summary Route 
D 192.168.3.0/24 [90/2835456] via 172.16.1.1, 00:34:11, SerialO.1 
D 182.0.0.0/8 [90/2313984] via 172.16.1.1, 00:34:11, Serial0O.1 = summary Route 


mexico_1# 


usa_l#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M —- mobile, B - BGP 
D — EIGRP, EX — EIGRP external, O — OSPF, IA - OSPF inter area 
Nl - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U -— per-user static route, o —- ODR 


Gateway of last resort is 172.16.2.1 to network 0.0.0.0 


D 192.168.3.0/24 [90/409600] via 172.16.6.7, 00:45:52, Ethernet0 
D 192.168.4.0/24 [90/409600] via 172.16.6.7, 00:45:52, Ethernet0 
172.16.0.0/24 is subnetted, 2 subnets 
Ss 172.16.6.0 is directly connected, Ethernet0 
Cc 172.16.2.0 is directly connected, Serial0.1 
D* 0.0.0.0/0 [90/2185984] via 172.16.2.1, 00:44:54, Serial0d.1 
usa_l# 
NOTE 


In Cisco 1|OS Software 12.0(4)T, an administrative distance can be added to the 
summary address to alter the default admin distance of 90. 
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Default Routing with EIGRP 


A default route can be injected into EIGRP in two primary ways: 


e Redistribute a default static route into EIGRP so that EIGRP recognizes the route of 0.0.0.0 
to be the default route. A default static route is created with the global router entry ip route 
0.0.0.0 0.0.0.0 next_hop_|P_address. This route then must be redistributed into EIGRP with 
the redistribute static command. If the network 0.0.0.0 is not used, you can still mark the 
route as a default route by using the ip default-network a.b.c.d command. 

e Summarize a default route of 0.0.0.0 with the interface command ip summary-address 
eigrp as_ number 0.0.0.0 0.0.0.0. The example in the previous section demonstrated how 
to propagate a default route with this command. 


With both ways, the router needs the ip classless global command enabled. With IP classless, the 
router forwards any packets toward the default route that it does not have a more specific route 
toward. ip classless is enabled by default in Cisco |OS Software Release 12.0 and later. 


In Figure 11-11, the canada_1 router advertises a default route to usa_1 and mexico_1. canada_1 


does this by creating a static route pointing at a next-hop address of 172.16.3.3 or the canada_2 
router. 


Figure 11-11. EIGRP Default Routing 
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Example 11-27 lists the configuration of the canada_1 router advertising a default static route. 


Example 11-27 Advertising a Default Static Route with EIGRP on canada_1 


router eigrp 2001 
“~ redistribute the static routes 
network 172.16.0.0 
default-metric 16000 630 254 11500 “Don't forget the default-metric 
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no auto-summary 
! 


ip route 0.0.0.0 0.0.0.0 172.16.3.3 ‘~The default route points at Canada_i router 


Example 11-28 lists the route table of the mexico_1 router demonstrating how the default route is 


received. Notice that when the route is advertised, it is an external router because it is redistributed, 
and it has the * denoting it is the default route. The gateway of last resort also is set. 


Example 11-28 Route Table of the mexico_1 Router 


mexico_l#show ip route 
Codes: C - connected, S - static, I - IGRP, R -—- RIP, M —- mobile, B - BGP 
D — EIGRP, EX —- EIGRP external, O - OSPF, IA — OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * -— candidate default 
U - per-user static route, o - ODR 
T - traffic engineered route 


172.16.0.0/24 is subnetted, 5 subnets 


Cc 172.16.5.0 is directly connected, Ethernet0O 

D 172.16.6.0 [90/2707456] via 172.16.1.1, 00:04:15, Serial0d.1 

Cc 172.16.1.0 is directly connected, Serial0.1 

D 172.16.2.0 [90/2681856] via 172.16.1.1, 00:04:51, Serial0d.1 

D 172.16.3.0 [90/2185984] via 172.16.1.1, 00:04:51, Serial0d.1 

D 192.:168.4.0/24 [90/2835456] via 172.16.1.1, 00304215, SeriaLd.1 
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks 

D 10.1.2.0/30 [90/2313984] via 172.16.1.1, 00:04:51, SerialO.1 

D 10.12.1.0/24 [90/2313984]. via 172.16.1.1, 00¢04:52, Seriald.1 
182.16.0.0/24 is subnetted, 2 subnets 

D 182.16.4.0 [90/2313984] via 172.16.1.1, 00:04:52, Seriald.1 

D 162.1623%0 [90/2313984]) Wie 172. V6.lel; 0004252, Serrald.1. 

D 192..168..3.0/24 [90/2835456] via 172.16.1.1, 00:04915, Seriald.1 


mexico_1l# 
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EIGRP Stub Routing 


In Cisco |OS Software Release 12.0(7)T, Cisco introduced EIGRP stub routing to further control 
stability and reduce resource utilization. This feature was fully integrated into Release 12.0(15)S. 
EIGRP stub routing functions very much like that of an OSPF stub area. The stub router has one 
exit path from the routing domain and forwards all traffic to a central or distribution router. 
Another way to say this is that the stub network cannot be a transit router for EIGRP, and it can 
have only one EIGRP neighbor. 


When configuring EIGRP stub routing, only the remote or the spoke router needs to be configured 
as a stub. This router responds to queries for summaries, connected routes, redistributed static 
routes, external routes, and internal routes with the message "inaccessible." This process greatly 
reduces the overhead associated with responding to queries by the remote routers. The stub router 
also sends special peer information to its neighbor informing its neighbor that it is a stub router. 


To configure EIGRP stub routing, use the following router command under EI GRP: 
Router (config-router) #eigrp stub [receive-only | connected | static | summary] 
The options are described as follows: 

e receive-only— This causes the router to not send any routes. 


e connected— The router advertises all connected routes to the single neighbor. No 
redistribution is necessary. 


e static— The router advertises all static routes to a single neighbor. The static routes still 
need to be redistributed into ElGRP to be advertised. 


e summary— The router advertises summary routes. 


A stub router can be configured to advertise connected and static routes at the same time, which is 
the case in most stub domains. Figure 11-12 shows two EIGRP stub networks configured. The 
mexico_1 router is configured as a stub router that advertises only its local Ethernet network. The 
usa_1 router advertises its local Ethernet network along with two static routes to the 
192.168.3.0/24 and 192.168.4.0/24 networks. The usa_2 router has a default gateway pointing to 
172.16.6.6 and has no routing enabled. The distribution router is canada_1. No additional ElGRP 
configuration is necessary on the distribution router. 


Figure 11-12. EIGRP Stub Routing 
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Example 11-29 lists the EIGRP configuration of the mexico_1 and the usa_1 routers. 


Example 11-29 EI GRP Stub Configuration 


! 

hostname mexico_1 

! 

router eigrp 2001 

network 172.16.0.0 

default-metric 1544 100 254 1 1500 
no auto-summary 


hostname usa_l 
! 


router eigrp 2001 


‘“Redistribute static 
network 172.16.0.0 


default-metric 1544 100 254 1 1500 
no auto-summary 


SigED SEND connected serene "~ Set BIGRP stub, and advertise connected and static 
! 
ip classless 


ap route 192.168.3..0 255.259.255.0 1722165657 
ip route 192 .168.4.0 255.2559.255.0 172.16. 6..7 


Finally, by viewing the canada_1 route table, all routes are being reported by EIGRP in the correct 
manner. Example 11-30 lists the route table of the canada_1 router. 
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Example 11-30 Route Table of canada_1 with Two EIGRP Stub Domains 


canada_l#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M —- mobile, B - BGP 
D — EIGRP, EX — EIGRP external, O -— OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U - per-user static route, o — ODR 


Gateway of last resort is not set 


172.16.0.0/24 is subnetted, 5 subnets 


D 172.16.5.0 [90/2195456] via 172.16.1.5, 01:03:47, Seriald.1 

D 172.16.6.0 [90/2195456] via 172.16.2.6, 00:48:40, Serial0d.2 

Cc 172.16.1.0 is directly connected, Serial0.1 

Cc 172.16.2.0 is directly connected, Serial0.2 

ie 172.16.3.0 is directly connected, TokenRing0O 

D EX 192.168.4.0/24 [170/2195456] via 172.16.2.6, 00:43:27, Serial0.2 
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks 

D 10.1.2.0/30 [90/304128] via 172.16.3.3, 07:31:49, TokenRingO 

D 10.1.1.0/24 [90/304128] via 172.16.3.3, 07:31:49, TokenRingO 
182.16.0.0/24 is subnetted, 2 subnets 

D 182.16.4.0 [90/304128] via 172.16.3.3, 07:31:49, TokenRingO 

D 182.16.3.0 [90/304128] via 172.16.3.3, 07:31:49, TokenRingO 

D BX 192.168.3.0/24 [170/2195456] via 172.16.2.6, 00:43:28, Serial0.2 


canada_l# 


To verify that the router is configured as an EIGRP stub router, use the show ip eigrp neighbor 
detail command. The last line of the output will show whether stub routing is enabled and what 
the stub router can advertise. This output can be viewed in Example 11-41. The show eigrp 


packet stub command shows debug information about the stub status of the peer routers. 
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EIGRP Equal- and Unequal-Cost Load Balancing 


By default, EIGRP load-shares over four equal-cost paths. For load sharing to happen, the 
routes to load-share over must show up in the IP forwarding table or with the show ip route 
command. Only when a route shows up in the forwarding table with multiple paths to it will 
load sharing occur. Use the bandwidth interface command on serial links to ensure that 
EIGRP has a consistent perspective of the metrics of the network. This also might aid in 
making the route show up in the IP forwarding table. 


EIGRP also has the capability to use unequal-cost load balancing in the same manner as 
IGRP. The router uses variance as a multiplier in choosing the upper boundary of the path 
with the greatest metric. 


Configuring EIGRP unequal-cost load balancing is a three-step process: 


Step 1. Configure the bandwidth on both sides of all the interfaces involved in the 
load-sharing group. Use the bandwidth xx_kbps command to accomplish this. 


Step 2. Define the lowest-cost metric and the highest-cost metric. From these values, 
compute the variance multiplier and add it to the EIGRP routing process. The 
composite metric that EIGRP is using can be viewed with the show ip eigrp 
topology command, as discussed in previous sections. 


Step 3. (Optional) Set the maximum-paths or the traffic-share variables. 


The following example walks through the calculation of a fictional variance. EIGRP has a route 
whose metric is 100. The router also has two more routes to that same destination whose 
metrics are 200 and 300. To allow EIGRP to use all three paths in sharing data, you would set 
the variance to 3: 


3 x 100 = 300 


Another way to view it is as variance x lowest_ metric = largest metric of path to load-share 
over—in this case, 300. To properly set the variance in a real network, use the following 
formula: 


Variance = | + ( [metric of highest cast route / metric of the lowest cast route), rounded 
up to the nearest Is decimal place) 


The metric of the lowest-cost and highest-cost routes can be discovered with the show ip 
eigrp topology command. Be sure to change variance and any other variables, such as 
bandwidth, on both ends of the link. The bandwidth should be set on all serial links. The 
following is the syntax for the commands used in configuring load balancing: 


Router (config-router) variance [metric_multiplier 1-128] 
Router (config-router)maximum-paths [1-6] 
Router (config-router)traffic-share {balanced | min across-interface] 
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Router (config-router) bandwidth xx kbps 


The variance command defines the metric multiplier of which routes to use in unequal-cost 
load balancing. The default variance is 1, which is equal-cost load balancing. 


With the maximum-paths command, the router uses up to six paths to share traffic across; 
to limit this number, use the maximum-paths command. The multiple paths that make up a 
single-hop transport to a common destination are called a load-sharing group. The default 
value is 4. 


With the traffic-share command, if there are multiple minimum-cost paths and traffic- 
share-min is configured, EIGRP will use equal-cost load balancing. By default, the command 
is set to balanced, where traffic will be distributed proportionally to the ratio of the metrics. 
For example, if variance is set to 3 and traffic-share is set to balanced, the best route will 
transport traffic three times that of the worst route. 


For a route to be included in unequal-cost load sharing, three other conditions must be met: 


e The maximum-paths limit must not be exceeded as a result of adding this route to the 
load-sharing group. 

e The downstream router must be metrically closer to the destination. 

e The metric of the lowest-cost route, multiplied by the variance, must be greater than 
the metric of the route to be added to the load-sharing group. 


Chapter 10 provides a detailed example of load sharing over |GRP, which is syntactically 
identical to configuring EIGRP traffic load balancing. 
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Lab 22: EIGRP Route Redistribution, Summarization, and Stub 
Routing—Part | 


Practical Scenario 


As EIGRP networks continue to grow in popularity, it becomes increasingly important to be able to 
control the query range and integrate it with other routing protocols, such as RIP and OSPF. It is 
also important to understand the default setting of EIGRP, such as split horizon and 
autosummarization. 


This lab gives you practice in controlling the query range, integrating EIGRP with other routing 
protocols, and performing summarization. 


Lab Exercise 


Cisco Training Partners provide custom-tailored Cisco courses around the United States and are in 
the process of integrating their training facilities over a common network. Your task is to 
configure an EIGRP network using the following parameters as design guidelines: 


e Configure an |1P network, as depicted in Figure 11-13, using EIGRP as the routing protocol 
and 65001 as the Autonomous System ID. 


Figure 11-13. Cisco Training Partners Network 
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e Configure the Frame Relay network as a multipoint network between the wisconsin, 
georgia, and ohio routers. Configure the Frame Relay network as a point-to-point network 
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between the wisconsin and minnesota routers. 

Ensure full |1P reachability with the RIP domain without using static routes or advertising a 
default route. 

(Optional) Configure the georgia and ohio routers as EIGRP stub routers. The routers 
should advertise their local LAN networks in EI GRP. 


Lab Objectives 


Configure the Cisco Training Partners Network as depicted in Figure 11-13. Configure IP as 
denoted in the diagram. The LAN topology type is not important in this lab. 

Use Frame Relay data link protocol on the WAN. 

Configure redistribution between RIP and EIGRP. 

Ensure full 1P connectivity to all IP interfaces—that is, be sure that you can ping all Frame 
Relay and LAN interfaces from the RIP domain. Also ensure that the georgia and ohio 
routers can ping each others' Frame Relay and LAN interfaces. You cannot configure any 
static routes or default routes on the network. 

(Optional) Configure the georgia and ohio routers as EIGRP stub routers. You will need 
Cisco |OS Software Release 12.0(7)T or Cisco 1|OS Release 12.0(15)S or 12.1 and later, 
the T and S trains are required. 


Equipment Needed 


Six Cisco routers. Four will be connected through V.35 back-to-back cables or in a similar 
manner to a Frame Relay switch. 

Four LAN segments, provided through hubs or switches. The LAN topology is not 
significant to this lab. 


Physical Layout and Prestaging 


Connect the hubs and serial cables to the routers, as shown in Figure 11-13. 


The stillwater router will run RIP only on network 172.16.0.0. Configure this router at this 
time. See Chapter 9 if you need assistance on this. 


A Frame Relay switch with three PVCs also is required. Example 11-31 lists the Frame 


Relay configuration used in this lab. 


Example 11-31 Frame Relay Switch Configuration 


hostname frame_switch 


frame-relay switching 


<<<text omitted>>> 


interface Serial0O 


no ip address 

encapsulation frame-relay 

no fair-queue 

clockrate 148000 

frame-relay intf-type dce 

frame-relay route 111 interface Seriall 110 
frame-relay route 121 interface Serial3 102 
frame-relay route 150 interface Serial5 151 


interface Seriall 


no ip address 
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encapsulation frame-relay 

clockrate 148000 

frame-relay intf-type dce 

frame-relay route 110 interface SerialO 111 
! 
<<<text omitted>>> 

! 
interface Serial3 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay intf-type dce 

frame-relay route 102 interface SerialO 121 
! 

<<<text omitted>>> 

! 

interface Serial5 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay intf-type dce 

frame-relay route 151 interface Serial0O 150 
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Lab 22: EIGRP Route Redistribution, Summarization, and Stub 
Routing—Part Il 


Lab Walkthrough 


Configure the Frame Relay switch and attach the four routers in a back-to-back manner to 
the Frame Relay switch. Use V.35 cables or CSU/DSUs with crossover cables, to connect the 
routers. Create the four LANs by using switches or hubs/MAUs, as illustrated in Figure 11-13. 


When the physical connections are complete, assign IP addresses to all LAN and WAN 
interfaces, as depicted in Figure 11-13. Be sure that you can ping each router's local LAN 
and WAN interface before moving on. The wisconsin router will need subinterfaces; one will 
be a multipoint interface and one will be a point-to-point interface. You will use frame-relay 
map statements on the multipoint interface. You will use frame-relay interface-dlci 
commands on the point-to-point interface between the wisconsin and minnesota routers. For 
full IP connectivity, you will need an additional frame-relay map statement on ohio and 
georgia pointing toward each other. Example 11-32 lists the Frame Relay configuration, to 
this point, on all routers involved. 


Example 11-32 Frame Relay Configuration on wisconsin, georgia, 
ohio, and minnesota Routers 


! 
hostname wisconsin 
! 
<<<text omitted>>> 
! 
interface Serial0 
no ip address 
no ip directed-broadcast 
encapsulation frame-relay 
no ip mroute-cache 
frame-relay lmi-type cisco 
! 
interface Serial0O.1 multipoint 
ip address 192.168.1.1 255.255.255.248 
no ip directed-broadcast 
frame-relay map ip 192.168.1.2 121 broadcast 
frame-relay map ip 192.168.1.3 150 broadcast 
! 
interface Serial0.2 point-to-point 
ip address 192.168.2.1 255.255.255.0 
no ip directed-broadcast 
frame-relay interface-dlci 111 


! 
hostname georgia 

! 

<<<text omitted>>> 
! 

interface Serial0O 
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ip address 192.168.1.2 255.255.255.248 

no ip directed-broadcast 

encapsulation frame-relay 

no ip mroute-cache 

frame-relay map ip 192.168.1.1 102 broadcast 
frame-relay map ip 192.168.1.3 102 broadcast 
frame-relay lmi-type cisco 


hostname ohio 

! 

enable password cisco 

! 

<<<text omitted>>> 

! 

interface Serial0 

ip address 192.168.1.3 255.255.255.248 

no ip directed-broadcast 

encapsulation frame-relay 

no ip mroute-cache 

frame-relay map ip 192.168.1.1 151 broadcast 
frame-relay map ip 192.168.1.2 151 broadcast 
frame-relay lmi-type cisco 


hostname minnesota 

! 

<<<text omitted>>> 

! 

interface Serial0 

ip address 192.168.2.2 255.255.255.0 
encapsulation frame-relay 

no ip mroute-—cache 

frame-relay interface-—dlci 110 


After local WAN and LAN connectivity has been established, the network configuration will be 
divided into two parts. First, you will configure the EIGRP domain and then you will integrate 
RIP. 


The basic EIGRP configuration will be similar on all the routers. Following the three-step 
process, begin by enabling EIGRP on all the routers using the router eigrp 65001 
command. The second step is to define the networks to run EIGRP on. The wisconsin, 
georgia, and ohio routers will route E1GRP on the major networks of 172.16.0.0 and 
192.168:1.0. 


Therefore, use these networks for your network statements. The wisconsin and minnesota 
routers will run EIGRP on 192.168.2.0 in addition to 172.16.0.0. Because this is a Frame 
Relay network, it's a good idea to set the bandwidth statements. Set the bandwidth to 128 
kbps on the wisconsin interface sO.1 to accommodate the two 64-kbps PVCs. The georgia and 
ohio routers should have the bandwidth set to 64 kbps on the Frame Relay interfaces. The 
default bandwidth is 1.544 Mbps (T1 speed), so there is no need to modify it on the SO.2 
interface on the wisconsin router. Example 11-33 lists the configuration of the wisconsin 
router to this point. 
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Example 11-33 Configuration of the wisconsin Router 


hostname wisconsin 
! 
interface Ethernet0 
ip address 172.16.5.1 255.255.255.128 
no ip directed—-broadcast 
! 
interface Serial0 
no ip address 
no ip directed—-broadcast 
encapsulation frame-relay 
no ip mroute-cache 
frame-relay lmi-type cisco 
! 
interface Serial0.1 multipoint 
bandwidth 128 
ip address 192.168.1.1 255.255.255.248 
no ip directed—-broadcast 
frame-relay map ip 192.168.1.2 121 broadcast 
frame-relay map ip 192.168.1.3 150 broadcast 
! 
interface Serial0.2 point-to-point 
ip address 192.168.2.1 255.255.255.0 
no ip directed-broadcast 
frame-relay interface-—dlci 111 
! 
router eigrp 65001 
network 172.16.0.0 
network 192.168.1.0 


network 192.168.2.0 
! 


At first glance, it might appear that routing is working. After all, you have a route table and 
three EIGRP neighbors on the wisconsin router. But some EIGRP defaults must be disabled to 
make the network route properly. Notice in Example 11-34 that EIGRP has three neighbors in 
the route table. Unfortunately, the router also has injected a couple routes to null in its 
forwarding table. 


Example 11-34 show ip route and show ip eigrp neighbors Command 
Output on the wisconsin Router 


wisconsin#show ip route 
Codes: C -— connected, S - static, I - IGRP, R - RIP, M —- mobile, B - BGP 
D —- EIGRP, EX —- EIGRP external, O - OSPF, IA —- OSPF inter area 
Nl - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area 
* — candidate default, U - per-user static route, o — ODR 
P —- periodic downloaded static route 


Gateway of last resort is not set 


172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks 
Cc 172.16.5.0/25 is directly connected, Ethernet0O 
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D 172.16.0.0/16 is a summary, 00:10:58, Null0 
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks 


D 192.168.1.0/24 is a summary, 00:11:33, Null0 

Cc 192.168.1.0/29 is directly connected, Serial0O.1 
C 192.168.2.0/24 is directly connected, Serial0.2 
wisconsin# 


wisconsin#show ip eigrp neighbors 
IP-EIGRP neighbors for process 65001 


H Address Interface Hold Uptime SRIT RTO Q Seq Type 
(sec) (ms) Cnt Num 

2 192.168.1212 Se0.1 171 00:14:00 768 4608 0 4 

1 1922168. 13 Se0.1 152 00:14:11 1544 5000 0 4 

0 192.168 .42.2 Se0.2 157 00:14:22 O 3000 .0 Lt 

wisconsin# 


If you try to ping any routers in the 172.16.0.0 domain, it will fail. This is because the router 
is forwarding those packets to its null interface. 


You need to correct two problems: 


e The network has discontinuous subnets at the major bit boundaries. The major 
network 172.16.0.0/16 is divided by the networks 192.168.1.0/29 and 
192.168.2.0/24. To correct this problem, disable E1GRP autosummarization on all 
routers in the internetwork with the no auto-summary EIGRP router command. 

e Split horizon must be corrected, although this problem won't manifest itself until 
autosummarization is disabled. 


Example 11-35 lists the route table of the wisconsin router now that autosummarization is 


disabled throughout the network. Notice that the 172.16.2.0/24, 172.16.3.0/24, and 
172.16.5.0/24 routes are now in the forwarding table. 


Example 11-35 show ip route Command Output on the wisconsin 
Router 


wisconsin#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M —- mobile, B - BGP 
D — EIGRP, EX -— EIGRP external, O — OSPF, IA — OSPF inter area 
Nl - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area 
* — candidate default, U - per-user static route, o — ODR 
P —- periodic downloaded static route 


Gateway of last resort is not set 


172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks 


Cc 172.16.5.0/25 is directly connected, Ethernet0O 

D 172.16.6;:0/24 [90/20537600] wia 192.168.1.2, 00:01:47, Séeriald.1 

D 172.16.2.0/24 [90/40537600] via 192.168.2.2, 00:54:38, Serial0.2 

D 172.16.3.0/24 [90/20528128] via 192.168.1.3, 00:08:32, Serial0.1 
192.168.1.0/29 is subnetted, 1 subnets 

c 192.168.1.0 is directly connected, Serial0O.1 

C 192.168.2.0/24 is directly connected, Serial0.2 

wisconsin# 
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As mentioned previously, the other problem that you need to remedy is split horizon. If you 
test IP connectivity from strictly the wisconsin router, everything would appear normal. 
However, upon examining the forwarding table of the georgia and ohio routers, you will see 
that the georgia router does not have the 172.16.3.0/24 subnet. The ohio router also does 
not have the 172.16.6.0/24 subnet, as shown in Example 11-36. 


Example 11-36 show ip route Command Output on the ohio and 
georgia Routers 


ohio#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M —- mobile, B - BGP 
D —- EIGRP, EX —- EIGRP external, O - OSPF, IA —- OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area 
* — candidate default, U - per-user static route, o — ODR 
P —- periodic downloaded static route 


Gateway of last resort is not set 


172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks 


D 172.16.5.0/25 [90/40537600] via 192.168.1.1, 00:00:52, Serial0 
D 172.16.2.0/24 [90/41049600] via 192.168.1.1, 00:00:52, Serial0 
Cc 172.16.3.0/24 is directly connected, TokenRing0O 

192.168.1.0/29 is subnetted, 1 subnets 
‘a 192.168.1.0 is directly connected, Serial0O 


D 192..168.2.0/24 [90/41024000] via 192.168 .1.1, 00:00:53, Seriald 
ohio# 


georgia#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M —- mobile, B - BGP 
D - EIGRP, EX -—- EIGRP external, O -— OSPF, IA —- OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area 
* — candidate default, U - per-user static route, o — ODR 
P —- periodic downloaded static route 


Gateway of last resort is not set 


172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks 


D 172.16.5.0/25 [90/40537600)] vila 192.168.1.1, 00701:21, Seriald 

c 172.16.6.0/24 is directly connected, Ethernet0O 

D 172.16.2.0/24 [90/41049600] via 192.168.1.1, 00:01:21, Serial0d 
192.168.1.0/29 is subnetted, 1 subnets 

Cc 192.168.1.0 is directly connected, Serial0O 

D 192.168.2.0/24 [90/41024000] via 192.168.1.1, 00:01:21, Serial0 

georgia# 


These routes are not being propagated because of EIGRP split horizon. This can be verified 
with the debug ip eigrp packets command. To allow updates to flow properly across a 
multipoint network, disable split horizon on that interface with the no ip split-horizon eigrp 
command on the wisconsin sO.1 interface: 
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wisconsin(config) #int s0O.1 
wisconsin(config-subif) #no ip split—-horizon eigrp 65001 


Example 11-37 lists the forwarding tables of the ohio and georgia routers after split horizon 
has been disabled on the wisconsin router. 


Example 11-37 show ip route Command Output on the ohio and 
georgia Routers 


ohio#show ip route 
Codes: C -— connected, S - static, I - IGRP, R - RIP, M —- mobile, B - BGP 
D — EIGRP, EX -— EIGRP external, O — OSPF, IA —- OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area 
* — candidate default, U - per-user static route, o — ODR 
P —- periodic downloaded static route 


Gateway of last resort is not set 


172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks 


D 172:16.5.0/25 [90/40537600] via 192,168.11, 00700704, Seriald 
D 172.16.6.0/24 [90/41049600] via 192.168.1.1, 00:00:04, Serial0d 
D 172.16.2.0/24 [90/41049600] via 192.168.1.1, 00:00:04, Serial0d 
C 172.16.3.0/24 is directly connected, TokenRing0O 

192.168.1.0/29 is subnetted, 1 subnets 
C 192.168.1.0 is directly connected, Serial0O 
D 192.168.2.0/24 [90/41024000] via 192.168.1.1, 00:00:04, Serial0O 
ohio# 


georgia#show ip route 
Codes: C —- connected, S - static, I - IGRP, R - RIP, M —- mobile, B - BGP 
D —- EIGRP, EX — EIGRP external, O —- OSPF, IA —- OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area 
* — candidate default, U - per-user static route, o — ODR 
P —- periodic downloaded static route 


Gateway of last resort is not set 


172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks 


D 172.16.5.0/25 [90/40537600] via 192.168.1.1, 00:01:41, Serial0 

Cc 172.16.6.0/24 is directly connected, Ethernet0O 

D 172.16.2.0/24 [90/41049600] via 192.168.1.1, 00:01:41, Serial0d 

D 172.16.3.0/24 [90/41040128] via 192.168.1.1, 00:00:49, Serial0d 
192.168.1.0/29 is subnetted, 1 subnets 

Cc 192.168.1.0 is directly connected, Serial0O 

D 192.168.2.0/24 [90/41024000] via 192.168.1.1, 00:01:41, Serial0O 

georgia# 


At this point, you have full |1P connectivity to all routers except the stillwater router, which 
resides in the RIP domain. 
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To fully integrate the RIP domain into EGIRP, you must ensure that the configuration has two 
elements: 


e Mutual redistribution between RIP and EIGRP on the minnesota router 
e All EIGRP routes summarized on a 24-bit boundary, the bit boundary the RIP network 
is on 


To enable mutual redistribution on the minnesota router, use the redistribution and 
default-metric commands. Example 11-38 lists the configuration of the minnesota router. 


Example 11-38 EI GRP and RIP Configuration of the minnesota Router 


! 

router eigrp 65001 
redistribute rip 
network 172.16.0.0 
network 192.168.2.0 
default-metric 1544 100 254 1 1500 
no auto-summary 

! 
router rip 

redistribute eigrp 65001 
network 172.16.0.0 


default-metric 4 
! 


The stillwater router now starts to receive routes from the minnesota router; however, it can 
receive only routes that have a 24-bit mask. The stillwater router will not have routes to the 
Frame Relay multipoint network, 192.168.1.0/29, or the Ethernet network, 172.16.5.0/25 on 
the wisconsin router. For the stillwater router to receive these routes, you must configure two 
summary addresses on a 24-bit boundary, on the point-to-point subnet between the 
wisconsin and minnesota router. Example 11-39 lists the configuration needed on the 
wisconsin router. 


Example 11-39 EIGRP Summarization on the wisconsin Router 


! 

interface Serial0.2 point-to-point 

bandwidth 64 

ip address 192.168.2.1 255.255.255.0 

no ip directed-—-broadcast 

ip summary-address eigrp 65001 192.168.1.0 255.255.255.0 5 
ip summary-address eigrp 65001 172.16.5.0 255.255.255.0 5 
frame-relay interface-dlci 111 


Example 11-40 lists the IP forwarding table of the stillwater router, followed by three pings. 


To test complete IP connectivity, pings have been issued from the stillwater router to the 
networks that were not originally on a 24-bit boundary. 


Example 11-40 The show ip route Command Followed by a ping on 
the stillwater Router 
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stillwater#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M —- mobile, B - BGP 
D —- EIGRP, EX — EIGRP external, O —- OSPF, IA —- OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U - per-user static route, o —- ODR 


Gateway of last resort is not set 


R 192.168.1.0/24 [120/4] via 172.16.2.1, 00:00:01, Ethernet0 
192.168.2.0/24 [120/4] via 172.16.2.1, 00:00:01, Ethernet0 
172.16.0.0/24 is subnetted, 4 subnets 
172.16.5.0 [120/4] via 172.16.2.1, 00:00:01, Ethernet0 
172.16.6.0 [120/4] via 172.16.2.1, 00:00:01, Ethernet0 
172.16.2.0 is directly connected, Ethernet0O 
W72506.320 [120/74] wie 172.16.2.1, 00:00:01,. Ethernet0 
stillwater#ping 192.168.1.2 


ve) 
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Type escape sequence to abort. 

Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds: 
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/70/72 ms 
stillwater#ping 192.168.1.3 


Type escape sequence to abort. 

Sending 5, 100-byte ICMP Echos to 192.168.1.3, timeout is 2 seconds: 
Success rate is 100 percent (5/5), round-trip min/avg/max = 68/70/72 ms 
stillwater#ping 172.16.5.1 


Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.5.1, timeout is 2 seconds: 


The final part of this lab is optional and involves configuring the georgia and ohio routers as 
EIGRP stub routers. Both routers still must advertise their connected networks; therefore, 
they need to use the connected keyword with the eigrp stub command. The only routers 
that need to be configured as stub routers are georgia and ohio; no configuration is 
necessary on the wisconsin router. The syntax needed on both routers resembles the 
following: 


georgia(config-router) #eigrp stub connected 


To verify that a stub router is working, use the show ip eigrp neighbors detail command, 
as in Example 11-41. The last line of the output shows whether stub routing is enabled and 
what the stub router can advertise. pings also should be issued from the RIP domain to the 
newly configured stub areas to verify IP routing. 


Example 11-41 Verifying Stub Routing 


wisconsin#show ip eigrp neighbors detail 65001 

IP-EIGRP neighbors for process 65001 

H Address Interface Hold Uptime SRTT RTO Q Seq Type 
(sec) (ms) Cnt Num 
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2 192.168.4143 Se0.1 17800300753 52 1140 0 25 
Version 12.0/1.1, Retrans: 1, Retries: 0 
Stub Peer Advertising ( CONNECTED ) Routes 

1 192,168.12 Se0.1 156 00:03:11 209 1254 0 28 
Version 12.0/1.1, Retrans: 0, Retries: 0 
Stub Peer Advertising ( CONNECTED ) Routes 


0 192.168.2.2 Se0.2 130 O1207701 26 2280 0 33 
Version 11.3/1.0, Retrans: 1, Retries: 0 
wisconsin# 


The last example (11-42) lists the complete configuration of the georgia, wisconsin, and 
minnesota routers. 


Example 11-42 Configuration listings of georgia, wisconsin, and 
minnesota Routers 


hostname georgia 
! 
<<<text omitted>>> 
! 
interface Ethernet0 
ip address 172.16.6.1 255.255.255.0 
no ip directed-broadcast 
! 
interface Serial0 
bandwidth 64 
ip address 192.168.1.2 255.255.255.248 
no ip directed-broadcast 
encapsulation frame-relay 
no ip mroute-—cache 
fair-—queue 64 256 0 
frame-relay map ip 192.168.1.1 102 broadcast 
frame-relay map ip 192.168.1.3 102 broadcast 
frame-relay lmi-type cisco 
! 
router eigrp 65001 
network 172.16.0.0 
network 192.168.1.0 
no auto-summary 


eigrp stub connected 
! 


hostname wisconsin 

! 

<<<text omitted>>> 

! 

interface Ethernet0 

ip address 172.16.5.1 255.255.255.128 
no ip directed-broadcast 
! 
interface Serial0 

no ip address 

no ip directed-broadcast 
encapsulation frame-relay 
no ip mroute-—cache 
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frame-relay lmi-type cisco 

! 

interface Serial0.1 multipoint 

bandwidth 128 

ip address 192.168.1.1 255.255.255.248 

no ip directed-broadcast 

no ip split—-horizon eigrp 65001 

frame-relay map ip 192.168.1.2 121 broadcast 
frame-relay map ip 192.168.1.3 150 broadcast 
! 

interface Serial0.2 point-to-point 

ip address 192.168.2.1 255.255.255.0 

no ip directed-broadcast 


ip summary-address eigrp 65001 192.168.1.0 255.255.255.0 5 
ip summary-address eigrp 65001 172.16.5.0 255.255.255.0 5 


frame-relay interface-dlci 111 
! 

interface Seriall 

no ip address 

no ip directed-broadcast 
shutdown 

! 

interface BRIO 

no ip address 

no ip directed-broadcast 
shutdown 

isdn guard-timer 0 on-expiry accept 
! 
router eigrp 65001 

network 172.16.0.0 

network 192.168.1.0 

network 192.168.2.0 

no auto-summary 


hostname minnesota 
! 
<<<text omitted>>> 
! 
interface Ethernet2 
ip address 172.16.2.1 255.255.255.0 
media-type 10BaseT 
! 
<<<text omitted>>> 
! 
interface Serial0 
ip address 192.168.2.2 255.255.255.0 
encapsulation frame-relay 
no ip mroute-cache 
frame-relay interface-dlci 110 
! 
router eigrp 65001 
redistribute rip 
network 172.16.0.0 
network 192.168.2.0 
default-metric 1544 100 254 1 1500 
no auto-summary 
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! 
router rip 

redistribute eigrp 65001 
network 172.16.0.0 


default-metric 4 
' 
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Lab 23: Default Routing, Route manipulation, and Filtering in EIGRP 
Networks—Part | 


Practical Scenario 


Most networks today are connected to the Internet in some form. Connecting to the Internet 
usually requires a default route to be propagated throughout the network. The following lab gives 
you practice in controlling routes and propagating a default route throughout EIGRP. 


Lab Exercise 


Small groups of Internet coffee shops and their suppliers have pooled to leverage a common 
connection to the Internet. Solar Bucks Inc., G & S INC of Switzerland, and Barneys have decided 
to share common networks while providing new services to their customers. Some shops also 
have private networks and do not want them propagated to other coffee shops. Your task is to 
configure an EIGRP network using the following parameters as design guidelines: 


e Configure an |P network as depicted in Figure 11-14, using EIGRP as the routing protocol 
and 2001 as the Autonomous System ID. 


Figure 11-14. Internet Coffee Shop Network 
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Configure the Frame Relay network as a point-to-point network among all the routers. Do 
not create a multipoint network. 


e Do not allow any other shops to see the subnet 172.16.3.0/24 on the barneys router. 
e Inject a default route into the solar_bucks router pointing all traffic to the internet_router. 
e The direct Frame link between solar_bucks and g_and_s router is very expensive. 


Configure EIGRP so that traffic from g_and_s will go first to barneys and then to 
solar_bucks. If the PVC between barneys and g_and_s drops, traffic will flow directly from 
g_and_s to solar_bucks. 


Lab Objectives 
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e Configure the Internet Coffee Shop Network as depicted in Figure 11-14. Configure IP as 
denoted in the diagram. The LAN topology type is not important in this lab. 

e Use the Frame Relay data link protocol on the WAN. Use only point-to-point networks on 
the Frame Relay network. 

e Ensure full IP connectivity to all 1P interfaces—that is, be sure that you can ping all Frame 
Relay and LAN interfaces except those that are filtered. 

e Filter the network 172.16.3.0/24 from g_and_s and solar_bucks routers. 

Inject a default route into the solar_bucks router pointing all traffic to the internet_router. 

e Control routes so that the traffic from the g_and_s router passes through barneys before it 
hits the Internet. Traffic to 172.16.50.0/0 also should go through the barneys router. Do 
not use policy routing. 


Equipment Needed 


e Five Cisco routers. Three will be connected through V.35 back-to-back cables or ina 
similar manner to a Frame Relay switch. 

e Four LAN segments, provided through hubs or switches. The LAN topology is not 
significant to this lab. The Internet connection can be real or not; it does not affect the 
configuration of the router. 


Physical Layout and Prestaging 


e Connect the hubs and serial cables to the routers, as shown in Figure 11-14. 


Configure an additional router to serve as the connection to the Internet. Use EIGRP for 
the routing protocol. 
e A Frame Relay switch with three PVCs also is required. Example 11-43 lists the Frame 


Relay configuration used in this lab. 


Example 11-43 Frame Relay Switch Configuration 


hostname frame_switch 

! 

frame-relay switching 

! 

<<<text omitted>>> 

! 

interface Serial0 

no ip address 

encapsulation frame-relay 

no fair-queue 

clockrate 148000 

frame-relay intf-type dce 

frame-relay route 111 interface Seriall 110 
frame-relay route 121 interface Serial3 102 
! 

interface Seriall 

no ip address 

encapsulation frame-relay 

clockrate 148000 

frame-relay intf-type dce 

frame-relay route 110 interface SerialO 111 
frame-relay route 130 interface Serial3 131 
! 
interface Serial2 

no ip address 
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shutdown 

! 
interface Serial3 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay intf-type dce 

frame-relay route 102 interface SerialO 121 
frame-relay route 131 interface Seriall 130 
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Lab 23: Default Routing, Route Manipulation, and Filtering in EIGRP 
Networks—Part Il 


Lab Walkthrough 


Configure the Frame Relay switch and attach the three routers in a back-to-back manner to the 
Frame switch. Use V.35 cables or CSU/DSUs with crossover cables to connect the routers. Create 
the four LANs by the use of switches or hubs/MAUs, as illustrated in Figure 11-14. 


When the physical connections are complete, assign IP addresses to all LAN and WAN interfaces, 
as depicted in Figure 11-14. Be sure that you can ping each routers' local LAN and WAN interface 
before moving on. You will use frame-relay interface-dlici commands on the point-to-point 
interfaces among all the routers. Example 11-44 lists the Frame Relay configuration, to this point, 
on all routers involved. 


Example 11-44 Frame Relay Configurations 


hostname solar_bucks 

! 

<<<text omitted>>> 

! 

interface Serial0d 

no ip address 

no ip directed-broadcast 

encapsulation frame-relay 

no ip mroute-cache 

frame-relay lmi-type cisco 

! 

interface Serial0.1 point-to-point 

ip address 172.16.128.1 255.255.255.252 
no ip directed-broadcast 

frame-relay interface-dlci 121 

! 

interface Serial0.2 point-to-point 

ip address 172.16.128.5 255.255.255.252 
no ip directed-broadcast 


frame-relay interface-dlci 111 
! 


hostname g_and_s 

! 

<<<text omitted>>> 

! 

interface Serial0 

no ip address 

no ip directed-broadcast 
encapsulation frame-relay 

no ip mroute-cache 

frame-relay lmi-type cisco 

! 

interface Serial0.1 point-to-point 
ip address 172.16.128.2 255.255.255.252 
no ip directed-broadcast 
frame-relay interface-dlci 102 
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! 

interface Serial0.2 point-to-point 

ip address 172.16.128.9 255.255.255.252 
no ip directed-broadcast 


frame-relay interface-dlci 131 
! 


hostname barneys 
! 
<<<text omitted>>> 
! 
interface Serial0d 
no ip address 
encapsulation frame-relay 
no ip mroute-cache 
! 
interface Serial0.1 point-to-point 
ip address 172.16.128.6 255.255.255.252 
frame-relay interface-dlci 110 
! 
interface Serial0.2 point-to-point 
ip address 172.16.128.10 255.255.255.252 


frame-relay interface-dlci 130 
! 


The basic EIGRP configuration for this lab is far simpler than that of the previous lab. There are no 
discontinuous subnets; therefore, you do not have to disable EIGRP autosummarization. The 
Frame Relay network is a point-to-point network, thereby making split horizon a nonissue, as 
well. Following the three-step process for configuring EIGRP, you simply need to enable El GRP 
routing and assign the AS number of 2001. You will use the network statement of 172.16.0.0 on 
each router. This is all that you need to configure for basic EIGRP routing. Because the PVCs to 
the g_and_s router are only 64 kbps, set the bandwidth to 64 on all the Frame Relay links to the 
g_and_s router. The EIGRP portion of the solar_bucks router, which resembles all the EIGRP 
configurations to this point, is presented in Example 11-45. 


Example 11-45 EI GRP Configuration of All Routers to This Point 


! 
router eigrp 2001 


network 172.16.0.0 
! 


At this time, you can verify routing by performing source pings and examining the route table. 
When basic routing is working, you can proceed to the next portion of the lab, which requires that 
barneys not propagate the subnet 172.16.3.0 throughout the EIGRP domain. There are many 
ways to accomplish this, but for this lab, you will use a distribution list. The list will be applied to 
EIGRP updates leaving the sO.1 and sO.2 interfaces on the barneys router. Example 11-46 
demonstrates the configuration of an access list denying the network 172.16.3.0/24 only. Access 
list 10 then is called by the distribution list in EIGRP. The distribution list must be applied to serial 
interfaces sO.1 and sO.2 to prevent the route from leaking back into the network. 


Example 11-46 Configuration of a Distribution List 


barneys (config) #access-list 10 deny 172.16.3.0 0.0.0.255 
barneys (config) #access-—list 10 permit any 
barneys (config) #router eigrp 2001 
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barneys (config-router) #distribute-list 10 out serial 0.1 
barneys (config-router) #distribute-list 10 out serial 0.2 
barneys (config-router) #*z 


By observing the forwarding table on g_and_s in Example 11-47, you can see that the route 


172.16.3.0/24 is now missing. You still can ping the 172.16.20.0/24 subnet, so you know that 
the filter was a success. 


Example 11-47 Testing a Route Filter 


g_and_s#show ip route 


Codes: C —- connected, S - static, I - IGRP, R - RIP, M — mobile, B - BGP 


D —- EIGRP, EX — EIGRP external, O — OSPF, IA —- OSPF inter area 
N1 - OSPF NSSA external type 1, N2 —- OSPF NSSA external type 2 
El —- OSPF external type 1, E2 -— OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, ia -—- IS-IS inter area 
* — candidate default, U - per-user static route, o — ODR 
P — periodic downloaded static route 
Gateway of last resort is not set 
172.16.0.0/16 is variably subnetted, 7 subnets, 3 masks 
@ 172.16.128.8/30 is directly connected, Serial0.2 
D 172.16.128.4/30 [90/41024000] via 172.16.128.1, 00:05:14, SerialO.1 
[90/41024000] via 172.16.128.10, 00:05:14, Serial0.2 
C 172.16.128.0/30 is directly connected, Serial0.1 
Cc 172.16.60.0/24 is directly connected, Ethernet0O 
D 172.16.50.0/24 [90/40537600] via 172.16.128.1, 00:05:14, SerialO.1 
D 172.16.20.0/24 [90/40537600] via 172.16.128.10, 00:05:13, Serial0.2 
D 172.16.0.0/16 is a summary, 01:10:38, Null0 
g_and_s#ping 172.16.20.1 


Type escape sequence to abort. 


Sending 5, 100-byte ICMP Echos to 172.16.20.1, timeout is 2 seconds: 


Success rate is 100 percent 
g_and_s# 


(5/5), round-trip min/avg/max 40/41/44 ms 


The next portion of the lab requires solar_bucks to inject a default route into the EIGRP domain. 
To accomplish this task, configure a default static route pointing all traffic to the internet_routers 
Ethernet port, 172.16.50.1. For the routers to use the default network, ensure that IP classless is 
enabled. The static route is redistributed into EIGRP. Example 11-48 demonstrates the 


configuration of the default route on the solar_bucks router. 


Example 11-48 Configuring a Default Route for EI GRP 


solar_bucks (config) #ip route 0.0.0.0 0.0.0.0 172.16.50.1 
solar_bucks (config) #router eigrp 2001 

solar_bucks (config-router) #redistribute static 

solar_bucks (config-router) #default-metric 1544 100 254 1 1500 
solar_bucks (config-router) #*Z 

solar_bucks# 


By viewing the route or forwarding table on g_and_s or barneys, you can see that the default 
route is being propagated and is marked as an external, default candidate route, as shown in 
Example 11-49. 
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Example 11-49 Viewing the Default Route on Barneys 


Codes: C —- connected, S - static, I - IGRP, R - RIP, M — mobile, B - BGP 
D —- EIGRP, EX — EIGRP external, O —- OSPF, IA — OSPF inter area 
N1 - OSPF NSSA external type 1, N2 —- OSPF NSSA external type 2 
El —- OSPF external type 1, E2 —- OSPF external type 2, E —- EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U -— per-user static route, o — ODR 


172.16.0.0/16 is variably subnetted, 7 subnets, 3 masks 


Cc 172.16.128.8/30 is directly connected, Serial0.2 

D 172.16.128.4/30 [90/41024000] via 172.16.128.1, 00:20:43, SerialO.1 
[90/41024000] via 172.16.128.10, 00:20:43, Serial0.2 

@ 172.16.128.0/30 is directly connected, Serial0.1 

c 172.16.60.0/24 is directly connected, Ethernet0 

D 172.16.50.0/24 [90/40537600] via 172.16.128.1, 00:20:43, SerialO.1 

D 172.16.20.0/24 [90/40537600] via 172.16.128.10, 00:20:42, Serial0.2 

D 172.16.0.0/16 is a summary, 01:26:07, Null0 
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The final phase of the lab involves influencing EIGRP routing decisions. In the previous example, 
g_and_s is using solar_bucks as the preferred route to the Internet. By changing the delay on this 
link, you can affect the route table so that the barneys router is the preferred path to the 
Internet. To accomplish this, use the delay 1000 command on each side of the PVC going 
between the g_and_s router and solar_bucks. Example 11-50 lists the route table of g_and_s, 
showing all routes now going through barneys first. A source trace can be performed to further 
test the configuration. 


Example 11-50 Route Table of g_and_s After the Delay Was I mplemented 


g_and_s#show ip route 
Codes: C -— connected, S - static, I - IGRP, R - RIP, M — mobile, B - BGP 
D —- EIGRP, EX — EIGRP external, O — OSPF, IA — OSPF inter area 
N1 - OSPF NSSA external type 1, N2 -— OSPF NSSA external type 2 
El —- OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, ia -— IS-IS inter area 
* — candidate default, U - per-user static route, o — ODR 
P — periodic downloaded static route 


Gateway of last resort is 172.16.128.10 to network 0.0.0.0 


172.16.0.0/16 is variably subnetted, 7 subnets, 3 masks 


Cc 172.16.128.8/30 is directly connected, Serial0.2 
Cc 172.16.128.0/30 is directly connected, Serial0.1 
Cc 172.16.60.0/24 is directly connected, Ethernet0 
D 172.16.0.0/16 is a summary, 01:28:54, Null0 
g_and_s# 


Example 11-51 lists the final configurations. 
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Example 11-51 Final Router Configurations for the I nternet Coffee Shop 
Network 


hostname solar_bucks 
! 
<<<text omitted>>> 
! 
interface Ethernet0O 
ip address 172.16.50.5 255.255.255.0 
no ip directed-broadcast 
! 
interface Serial0 
no ip address 
no ip directed-broadcast 
encapsulation frame-relay 
no ip mroute-cache 
frame-relay lmi-type cisco 
! 
interface Serial0.1 point-to-point 
bandwidth 64 
ip address 172.16.128.1 255.255.255.252 
no ip directed-broadcast 
delay 1000 
frame-relay interface-dlci 121 
! 
interface Serial0.2 point-to-point 
ip address 172.16.128.5 255.255.255.252 
no ip directed-broadcast 
frame-relay interface-dlci 111 
! 
<<<text omitted>>> 
! 
router eigrp 2001 
redistribute static 
"Optional 12.0 way, listed for example only 
network 172.16.0.0 
default-metric 1544 100 254 1 1500 
! 
ip classless 
ip route 0.0.0.0 0.0.0.0 172.16.50.1 


hostname g_and_s 
! 
<<<text omitted>>> 
! 
interface Ethernet0O 
ip address 172.16.60.1 255.255.255.0 
no ip directed-broadcast 
! 
interface Serial0d 
no ip address 
no ip directed-—broadcast 
encapsulation frame-relay 
no ip mroute-cache 
frame-relay lmi-type cisco 
! 
interface Serial0.1 point-to-point 
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bandwidth 64 

ip address 172.16.128.2 255.255.255.252 
no ip directed—-broadcast 

delay 1000 

frame-relay interface-dlci 102 

! 
interface Serial0.2 point-to-point 
bandwidth 64 

ip address 172.16.128.9 255.255.255.252 
no ip directed-broadcast 

frame-relay interface-dlci 131 

! 
router eigrp 2001 

network 172.16.0.0 

! 

ip classless 


hostname barneys 
! 
<<<text omitted>>> 
! 
interface Ethernet2 
ip address 172.16.20.1 255.255.255.0 
media-type 10BaseT 
! 
<<<text omitted>>> 
! 
interface Serial0O 
no ip address 
encapsulation frame-relay 
no ip mroute-cache 
! 
interface Serial0.1 point-to-point 
ip address 172.16.128.6 255.255.255.252 
frame-relay interface-dlci 110 
! 
interface Serial0.2 point-to-point 
ip address 172.16.128.10 255.255.255.252 
bandwidth 64 
frame-relay interface-dlci 130 
! 
<<<text omitted>>> 
! 
router eigrp 2001 
network 172.16.0.0 
distribute-list 10 out Serial0O.1 
distribute-list 10 out Serial0.2 
! 
ip classless 
! 
access-list 10 deny 172.16.3.0 0.0.0.255 
access-list 10 permit any 
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Chapter 12. Link-State Protocols: Open Shortest Path 
First (OSPF) 


Since its conception in 1987, OSPF has continued to evolve with the modern internetwork. 
Today, OSPF is clearly the dominant Open Systems interior routing protocol. Because of the 
constant RFC enhancements to OSPF, it has proven itself to be a scalable protocol with 
networks in the tens of thousands of nodes. 


OSPF officially was documented in 1989 by the Internet Engineering Task Force (IETF) to 
address many of the limitations of distance vector protocols, such as RIP and IGRP. Since 
1989, OSPF evolved through several RFCs, beginning with Version 1 in RFC 1131 and moving 
to Version 2 in RFC 1247, which was superceded by RFC 2178, to its final form, Version II in 
RFC 2328. In modern large networks, OSPF become the standard open routing protocol. The 
word open is used because the algorithm that drives OSPF, Dijkstra's Shortest Path First 
(SPF) algorithm, isn't proprietary to any vendor or organization. This allows for mainframes 
such as IBM, Unisys, and DEC, as well as other manufacturers' routers, to run OSPF. 


As previously mentioned, OSPF provides many significant enhancements over current 
distance vector protocols: 


e Fast convergence— OSPF uses a reliable flooding mechanism to update neighboring 
routers of changes in network topology. Only partial routing updates are sent upon 
the loss of a route. These two facts, combined with the fact that all routers in the 
OSPF domain have a nearly identical view of the network, allow for OSPF to converge 
quickly. 


e Support for VLSM, supernetting, and summarization— OSPF can use 
summarization and VLSM to conserve address space and streamline routing. 


e Support for large network diameters— By using VLSM and forcing hierarchical 
network design based on areas, the OSPF network diameter is virtually limitless. 


e Stub area routing— Large networks are supported because stub-area routing 
reduces the routing table. 


e Efficient and reliable transport of routing updates— Through the use of two 
reserved multicast addresses to transport routing updates, OSPF does not impact non- 
OSPF routers and devices. OSPF updates are reliable because they all are implicitly or 
explicitly acknowledged. 


e Efficient use of media— Multicasts messages occur only on broadcast media. 
Unicast are used on NBMA and point-to-point networks. 


e Arbitrary metric based on cost— OSPF uses a metric of cost, which can be 
changed, to base routing decisions on. 


e Equal-cost load balancing— OSPF load-shares across equal-cost paths, optimizing 
bandwidth and multiple paths. 


e Support for Type 1 and Type II (MD5) authentication— OSPF allows for secure 
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route exchange by using Type 1 clear-text passwords or Type 2 MD5 authentication. 


e Support for route tagging of OSPF external routes— Tags can be added to 
external routes redistributed into OSPF. Tags can be used as another control for 
routing policy within the autonomous system or for internal documentation. 


e Fully classless routing protocol— OSPF supports a classless route table lookup and 
is not susceptible to classful routing problems, such as discontiguous subnets. 


e No susceptibility to split-horizon issues. 


In spite of these advantages, OSPF has been criticized as being overly complicated to 
configure and requiring high processor utilization. It is true that even the smallest OSPF 
network will require a small amount of design before implementation, and it does require 
more CPU cycles than other routing protocols. However, with the advent of modern CPUs, the 
amount of processor utilization for OSPF can be minimal. In this chapter, the technical 
operation of OSPF is discussed along with the configuration aspects of OSPF. 
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Technical Overview of OSPF 


OSPF is classless routing protocol that interfaces directly to |P as protocol 89. OSPF uses the 
concept of multicast hellos and dead timers to discover and maintain neighbors. Routing updates for 
OSPF are called link-state advertisements (LSAs). The topology table for OSPF commonly is referred 
to as the link-state database. OSPF floods areas with LSAs until every router in the domain has a 
consistent image of the network, called the link-state database. When every router has the same 
image of the network, the SPF algorithm, or the Dijkstra algorithm, is run on the database, and a 
loop-free graph describing the shortest-cost path to each destination in the network is created. This 
is called the SPF tree. The OSPF routes in the route table or forwarding table are derived from the 
SPF tree. Because each router has an identical copy of the entire SPF tree, rapid convergence is 
possible. OSPF uses an arbitrary metric of cost when determining the shortest path to a destination. 


Let's take a look at the major steps that OSPF goes through in building a route table, followed by a 
detailed examination of those steps. It is important to understand how OSPF operates over the 
different types of links and what type of LSAs propagates from one area to another. These details 
can be important when configuring OSPF over different media types. 


1. When OSPF initializes, it sends hello packets out all OSPF interfaces on the multicast address 
of 224.0.0.5, called the AllSPFRouter address, on broadcast and point-to-point networks. The 
hello is unicast to specific neighbors on NBMA and multipoint networks. A router that 
receives the hello then verifies it against its own information about the network. The OSPF 
hello packet is a lot more complicated than that of EIGRP. As you will see, OSPF actually 
exchanges data within the hello packet. 


2. When the packet has been verified, a neighbor is formed between the two routers. 
Neighbors, in turn, might or might not form adjacencies. An adjacency can be thought of as 
a virtual link between to routes used to send routing information on. 


3. Each router sends its link-state information to the new neighbor. 
4. Each neighbor records the new information and floods it to all its existing neighbors. 


5. All routers receive the link-state information and build identical link-state databases. When 
the databases are complete, each router runs the SPF algorithm. The algorithm generates a 
loop-free path to every known route, with the local router as root. This is called the SPF tree. 


6. Routes fitting the proper criteria from the SPF database then are inserted into the route table 
or forwarding database on the router. 


Now, let's examine some of the more significant elements in greater detail. 


OSPF Hello Protocol 


As mentioned previously, the hello protocol in OSPF actually carries important information and forms 
the adjacency. By default, the hello packet is sent out every 10 seconds on all OSPF interfaces. On 
NBMA networks, the default hello is 30 seconds. The hello packet accomplishes these tasks: 


e Neighbor discovery— When a router receives a hello, the packet contains the following 
information: 


- The router ID of the originating router 


- The area ID of the originating router interface 735 


- The address mask of the originating interface 

- Authentication type and authentication information for the originating interface 
- The Hellolnterval of the originating interface 

- The RouterDeadI nterval of the originating interface 

- The router priority 

- The designated router (DR) and backup designated router (BDR) 

- Five flags for options 


- The router IDs of the originating router's neighbors 
Adjacency criteria— For OSPF to form an adjacency between two neighbors, the 
Hellolnterval, RouterDeadInterval, area IDs, and authentication type and password must 
match. 


Keepalive mechanism between neighbors— The RouterDeadInterval is set to four times 
the hello timer. In most cases, this is 40 seconds or 120 seconds, depending on the link 
type. If a hello is not received by the time the RouterDeadI nterval expires, the neighbor is 
declared down. 


Election of DRs and BDRs on broadcast and NBMA networks— The router |D, DR, and 
BDR fields, along with the router priority, help determine the state of DRs and BDRs. More 
information on DR and BDRs is offered in upcoming sections. 


NOTE 


Sometimes, the terms neighbors and adjacencies are used synonymously. In OSPF, the 
terms are related but mean different things. RFC 2328 defines neighboring routers as 
routers that have interfaces to a common network. Neighbors are maintained by and 
usually are dynamically discovered by OSPF's Hello Protocol. Adjacency is defined as a 
relationship formed between selected neighboring routers for the purpose of 
exchanging routing information. Not every pair of neighboring routers becomes 
adjacent. 


OSPF Neighbors and Network Types 


The old Frost poem about neighbors reads as true for OSPF as it did for EIGRP: "Good neighbors 
make good networks." As in EIGRP, link states can be exchanged only after the neighbors build 
adjacencies. Stable OSPF neighbors are important in OSPF networks. How OSPF treats the neighbor 
and propagates link states depends on the network type that the router and its neighbor(s) exist on. 
There are five types of OSPF networks: 


Point-to- point networks— Examples of point-to-point networks are HDLC networks, PPP, 
and Frame Relay networks with point-to-point subinterfaces. Link states and hellos use the 
multicast address of 224.0.0.5. There is no designated router or BDR election. This is a Cisco- 
specific network type and is not defined by an RFC. 
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e Broadcast networks— Examples include Ethernet, Token Ring, and FDDI networks. Hellos 
use the address 224.0.0.5 and elect a DR and a BDR. The other routers on this network send 
link states on the multicast address of 224.0.0.6. Only the DR and the BDR listen to these 
updates on this address. They, in turn, flood the link states out address 224.0.0.5 for the 
other routers. The election and the role of the DR and BDR are discussed more in the next 
section. 


e NBMA networks— NBMA network types include Frame Relay natural or multipoint 
interfaces and X.25 networks. On networks such as these, multicast packets are not 
forwarded properly to all neighbors because there exists no broadcast capability. Therefore, 
OSPF neighbors must be statically defined. A DR and a BDR are elected, and all OSPF 
packets are unicast. On NBMA networks, the DR/BDR should be the router(s) that have a 
PVC, SVC, or circuit to all the other routers, or what is called the hub router(s). 


e Point-to-multipoint— Point-to-multipoint network types must be statically defined. The 
router treats a Frame Relay multipoint network like many point-to-point links. A DR and BDR 
are not elected, and OSPF packets are multicast. 


e Virtual links— Virtual links are a special type of network that is used to extend Area 0. 
Virtual links are discussed more in the section "OSPF Virtual Links." 


Designated Routers and Backup Designated Routers 


On multiaccess networks, such as Ethernet, Token Ring, or FDDI, it quickly becomes inefficient for 
every adjacent router to advertise link states to all its neighbors. It also becomes inefficient for 
every router to become adjacent. Instead, OSPF elects one router and calls it the designated router. 
The designated router listens to link states on 224.0.0.6 and floods them on address 224.0.0.5. This 
is the only router besides the backup designated router that will listen for link-state updates on 
224.0.0.6. The BDR will shadow the DR and take over only when the DR fails. Essentially, the DR/ 
BDR scheme offers the following advantages: 


e It streamlines routing updates through managing the flooding link states. 

e DR and BDR represent the multiaccess network to the rest of the OSPF domain. By acting as 
a single point of control, the DR also ensures that routers on the multiaccess network have 
consistent link-state information. 

e The concept of a BDR also speeds network synchronization. Because all routers are also 
adjacent to the BDR, if the DR fails, the BDR takes its place with minimum unavailability. 


When the DR and the BDR are elected, new routers will establish adjacencies only with the DR and 
the BDR. The DR and the BDR also become adjacent with each other. 


To elect the DR and BDR, the router will adhere to the following process: 


1. Neighbors participating in the election must be in at least the 2-way state. That is, each 
neighbor has sent and received a hello from the other neighbors participating. See the 
section entitled "The Basic OSPF Adjacency." 


2. Priority values will be examined. Neighbors with the priority value of 0 are excluded from the 
process. The neighbor with the highest priority becomes the BDR. In case of a tie, the router 
with the highest RID wins. The default OSPF priority is 1, which can be modified with the ip 
ospf priority [0-255] interface command. 


3. If no DRs are reported on the link, the BDR is promoted to DR, and the process begins again 
to select a new BDR. If there is a tie in the network, the tie is resolved by the router 1D. The 
router with the highest router |D becomes the BDR. 
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4. |f a router with a higher priority is added to the network, a new DR or BDR will not be 
selected. The DR/BDR election process happens again only if the DR or BDR fails. 


5. The routers continue to exchange hellos every 10 seconds (the default on broadcast 
networks). If a router does not receive a hello from a neighbor within the amount of time 
specified by the dead timer interval, which is four times the hello interval, the neighbor is 
declared down. 


Essentially, the election of a DR and a BDR allows OSPF to streamline routing updates through the 
network. In the Ethernet example in Figure 12-1, you can see how inefficient the routing process 
would quickly become in a large network. Without the DR/BDR, every router would need to 
exchange LS information with every other router on the network. 


Figure 12-1. OSPF Ethernet Network LS Propagation Without a DR and BDR 
(Hypothetical) 


With a DR and BDR in place (see Figure 12-2), LS information, or route information, is controlled by 
the DR. 


Figure 12-2. LS Propagation with a DR and BDR 
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OSPF Router IDs (RIDs) 


The OSPF router ID (RID) is 32-bit unique number assigned to each router running OSPF. This 
number uniquely identifies the router within the autonomous system. By having a unique router ID 
for every router within the AS, OSPF can accomplish the following: 


e OSPF easily can identify duplicate LSAs. 

e OSPF is used to identify the unique end points of virtual links. 

e OSPF is used to determine the tie-breaker for DR and BDR negotiations, as mentioned 
previously. 


The router ID is chosen among the interfaces configured for IP on the Cisco router. The router 
chooses the highest IP address from any operational IP interface. That is, the line is up and the line 
protocol is up for that interface. If a loopback address is configured on the router, the router 
chooses that address. If multiple loopback interfaces are configured, it chooses the loopback 
interface with the highest IP address. 


To force a router ID, use a loopback interface with a high IP address, such as 192.168.200.X. It is 
not necessary to propagate this network in a routing protocol. The networks—or, more specifically, 
the IP host addresses used for router |Ds—do not need to be reachable or "ping-able" addresses. In 
Cisco |OS Software Version 12.0 and above, the OSPF router ID can be hard-coded with the OSPF 
router command: 


Router (config-router) #router-id ip address 


TIP 


It is highly recommended to set the router ID with router-id command or by using 
loopback interfaces. This can greatly increase OSPF network stability. For example, 
OSPF virtual links rely on the router ID. If the router |D is not fixed and a new network 
or loopback interface is added to that router, the router |D would be recalculated upon 
a failure of that router. This could then lead to a change in routers IDs, making the 
virtual link fail. 
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The Basic OSPF Adjacency 


OSPF neighbors go through states before they can begin exchanging LSAs, as illustrated in Figure 
12-3. These states are referred to as the neighbor state machine. You can examine the state of an 
OSPF neighbor with the show ip ospf neighbor command. 


Figure 12-3. A Basic OSPF Adjacency 


alpha bravo 


a 224.0.0.5 hello 
wn | Set DR=0.0.0.0 nil 


a 224.0.0.5 hello ini 
nit 
| see alpha as a neighbor now 


int, —————s- 224.0.0.5hello 
| see bravo as a neighbor now 


224.0.0.5 hello 
Here's my router |D —————————-» 2-way 
Here's the router ID you sent 


224.0.0.5 hello 
2-way «——__—_—_—_———._ Here's my router ID 
Here's the router ID you sent 


DR/BDR Election process 


<< 
begins 


The following list briefly describes the OSPF neighbor states and how they operate: 


e Down-— This is the initial state of the neighbor, which also indicates that no hellos were 
heard from this neighbor within the last dead time interval. 


e Attempt— This state applies only to neighbors on NBMA networks, where the neighbors 
statically are configured with the neighbor command. When the interface becomes active, it 
goes to the ATTEMPT state, or when the router is DR or BDR. 


e Init— A hello packet has been received from the neighbor, but two-way communication 
hasn't taken place yet. 
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e 2-way-— This state indicates that a router has seen its own router ID in the Neighbor field of 
the Hello packet that it received from the neighbor. It also means that bidirectional 
conversation was established and that DR and BDR election can occur. 


When an OSPF interface first becomes active, it begins to send hello packets. When two routers 
receive each other's hello, they place the neighbor in init status. When a neighbor is in init status, it 
places its own router ID into the hello packet. When a router receives one of the new hellos with the 
router ID of its neighbor, it places the neighbor in a new state of 2-way. The 2-way state ensures 
that there is two-way communication between the routers. The routers must be in this state before 
they can negotiate a DR/BDR and exchange LSAs. 


After the routers have achieved the 2-way state, OSPF enters its final states: 


e ExStart— The router enters a master/slave relationship and prepares for the exchange of 
database description packets. The neighbor with the highest interface address becomes the 
master. 


e Exchange— The router sends its database description packets to neighbors in the exchange 
state. The database description packets describe the entire link-state database. The link- 
state database is synchronized after this phase. After synchronization, the router enters one 
of two final states: 


- Loading— The router also sends link-state request packets to all neighbors that are 
in the loading state. The loading phase requests that more recent LSAs be sent. 


- Full— Neighbors in this state are fully adjacent. 
In summary, the OSPF adjacency is built in four phases: 
1. Neighbors are discovered. 
2. Bidirectional communication is established between neighbors. 
3. The SPF database is synchronized. 
4. Full adjacency is formed. 


You can view the status of an OSPF adjacency with the show ip ospf neighbor command, and you 
can observe the actual building of the adjacency with the debug ip ospf adj command. These and 
other OSPF status commands are discussed more in upcoming sections. 


In Figure 12-4, the charlie router is added to an existing OSPF network. By enabling the debug 
command, you can observe the adjacency being built, as demonstrated in Example 12-1. 


Figure 12-4. A Basic OSPF Adjacency Demonstration 
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DR 


E1 
IP-172.16,1, 10/24 


EO 


BOR IP-172,16.1.1/24 


£0 
IP-172.16,1,5/24 


Example 12-1 debug ip ospf adj Command Followed by a show ip ospf 
neighbor Command Demonstrating an Adjacency Forming 


charlie#debug ip ospf adj 
OSPF adjacency events debugging is on 


OSPF: Interface Ethernet0O going Up 

OSPF: Build router LSA for area 0, router ID 172.16. 
OSPF: Build router LSA for area 0, router ID 172.16. 
OSPF: Build router LSA for area 0, router ID 172.16. 
SSYS-5-CONFIG_I: Configured from console by console 


PEERS 72s Way Sv enman Pes tion ye oneal oer son Behermetur state evar] «=O Reweerrenters 
OSPF: Build router LSA for area 0, router ID 172.16.1.1 


OSPF: 2 Way Communication to 172.16.1.5 on Ethernet0O, state 2WAY 
OSPF: Backup seen Event before WAIT timer on Ethernet0O 


— DR/BDR election begins 


PPR 
PPR 


OSPF: Elect BDR 172.16.1.5 
OSPF: Elect DR 172.16.1.10 

DR? 172.16.1.10 (Id) BDR? 172.16.1.5 (1d) 
OSPF: Send DBD to 172.16.1.5 on Ethernet0O seq 0x1370 opt Ox2 flag Ox7 len 32 
OSPF: Send DBD to 172.16.1.10 on Ethernet0O seq 0x218C opt 0x2 flag 0x7 len 32 
OSPF: Build router LSA for area 0, router ID 172.16.1.1 
OSPF: Rev DBD from 172.16.1.10 on EthernetO seq 0x1137 opt 0x2 flag Ox7 len 32 


a 


OSPF: NBR Negotiation Done. We are the SLAVE 
OSPF: Send DBD to 172.16.1.10 on Ethernet0O seq 0x1137 opt 0x2 flag 0x2 len 52 
OSPF: Rev DBD from 172.16.1.5 on Ethernet0O seq 0x16D9 opt 0x42 flag 0x7 len 32 


_ 


OSPF: NBR Negotiation Done. We are the SLAVE 
OSPF: Send DBD to 172.16.1.5 on Ethernet0O seq 0x16D9 opt 0x2 flag 0x2 len 52 
OSPF: Rev DBD from 172.16.1.10 on EthernetO seq 0x1138 opt 0x2 flag 0x3 len 92 


_" 


OSPF: Send DBD to 172.16.1.10 on Ethernet0O seq 0x1138 opt 0x2 flag 0x0 len 32 
OSPF: Database request to 172.16.1.10 

OSPF: sent LS REQ packet to 172.16.1.10, length 36 

OSPF: Rev DBD from 172.16.1.5 on EthernetO seq O0x16DA opt 0x42 flag 0x3 len 92 


oh 


OSPF: Send DBD to 172.16.1.5 on Ethernet0 seq 0x16DA opt 0x2 flag 0x0 len 32 7A2 


OSPF: Database request to 172.16.1.5 

OSPF: sent LS REQ packet to 172.16.1.5, length 36 

OSPF: Rev DBD from 172.16.1.10 on EthernetO seq 0x1139 opt 0x2 flag Oxl len 32 s 
tate EXCHANGE 

OSPF: Exchange Done with 172.16.1.10 on Ethernet0O 

OSPF: Send DBD to 172.16.1.10 on Ethernet0O seq 0x1139 opt 0x2 flag 0x0 len 32 


Ls database is 


: Build router LSA for area 0, router ID 172.16.1.1 
OSPF: Rev DBD from 172.16.1.5 on Ethernet0O seq 0x16DB opt 0x42 flag Oxl len 32 s 
tate EXCHANGE 
OSPF: Exchange Done with 172.16.1.5 on Ethernet0O 


~ The same "FULL" 


OSPF: Build router LSA for area 0, router ID 172.16.1.1 

OSPF: Send DBD to 172.16.1.5 on Ethernet0O seq 0x16DB opt 0x2 flag 0x0 len 32 
OSPF: Build router LSA for area 0, router ID 172.16.1.1 

charlie# 


charlie#show ip ospf neighbor 


Neighbor ID Pra State Dead Time Address Interface 
L72616.12:5 1 FULL/BDR 00300335 172 low ls 5 Ethernet0O 
1726166 1..410 iL FULL/DR 00300230 17241641 .10 Ethernet0O 
charlie# 


In this example, 172.16.1.10, or the alpha router, became the DR because its IP address is the 
highest one on the link. The next highest IP address was 172.16.1.5, or the bravo router, so it was 
elected as the BDR. 


Shortest-Path Tree (SPF) and the OSPF Metric Cost 


When the LS database is synchronized within an area, the Dijkstra algorithm is run against it in two 
passes to form the shortest-path (SPF) tree. The first pass against the SPF database forms the 
branches, or router adjacencies within the area. The second pass adds all leaves or stub networks to 
the tree. When OSPF builds the tree, it determines the shortest path to each destination based on 
the sum cost to the destination. The lower the cost is, the more preferred the route is. The cost of a 
route is the sum of all costs of outgoing interfaces to that destination. Oddly enough, RFC 2328 
offers no specific values for cost. Nortel Networks, for example, implements OSPF under RFC 2328 
and uses the same formula to generate cost as Cisco Systems. In multivendor environments, take 
the extra time to see how cost is calculated because it will help OSPF have a consistent view of the 
entire internetwork. 


Cisco routers calculate OSPF cost as (108/BW) rounded down, where BW is the configured or default 
bandwidth of the interface. Table 12-1 lists the common default OSPF cost settings. 


Table 12-1. Default OSPF Interface Cost 


Default Cost (1028/ 


Interface Type 


BW) 
FDDI, ATM, Fast Ethernet, Gigabit Ethernet (> 100 L 
Mbps) 
HSSI (45 Mps) 2 
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[16-Mbps Token Ring [6 
[10-Mbps Ethernet [10 
'4-Mbps Token Ring 23 

2 


T1 (1.544 Mbps) 


DS-O (64 kbps) 1562 
56 kbps 1785 
Tunnel (9 kbps) [21111 


The default cost values can be overridden with the ip ospf cost 1-65535 interface command. The 
cost for a route can be viewed with the show ip route command. Recall that the variable behind 
the administrative distance is the metric cost for the router. Figure 12-5 shows a quick example of 
how cost is calculated. The route table of the echo router lists the cost for network 172.16.2.0 to be 
70. The bandwidth of the T1 plus the 16-MB Token Ring equals 70; 64 + 6 = 70. The route to the 
Ethernet network has a cost of 80; 64 +6 + 10. 


Figure 12-5. OSPF Cost Calculation 


OSPF delta 1.544 Mbps echo 
AREA 100 COST=64 


$1-1P-172.16.3.1/24 S141P-172.16.3.1024 


1 16MB Token Ring Gateway of last resort is not set 
COST=6 


ToO-IP-172.16.2.1/24 


OSPF 


AREAO 172.16.0.0/24 is subnetted, 3 subnets 


OW $72.16.1.0 (110/80) via 172.16.3.1, 18:14:49, Serialt 
O  172.16.2.0 [110/70] via 172.16.3.1, 18:14:49, Sorinlt 
TOOIP-172.16.2.10/24 C 172,163.06 denctly commectod, Senall 
echor 


E1 
IP-172.16.1.10/24 


bravo 
BOR 


E0 
IP-172.16.1.1/24 


E0 
1P-172.16.1 S24 


OSPF Router Types, Areas, and LSAs 


At the onset, we mentioned that OSPF could be considered to be CPU-intensive and difficult to 
configure. By now, it becomes evident that multiple SPF databases, complex algorithms, and 
constant CPU interrupts caused by link-state flooding can cause an increase in the router's processor 
utilization. 


To control the flooding of link states and database synchronization, OSPF deploys the use of areas. 
An OSPF area can be defined as a group of routers and links that divide an OSPF domain into 
subdomains. Areas are identified by a 32-bit area 1D, which then also can be expressed in dotted- 
decimal notation or as a decimal number. 


There are five types of areas in OSPF: 
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e Backbone area or Area 0 (or 0.0.0.0) — All traffic must pass through the backbone area; 
nonbackbone areas do not exchange packets directly. All areas also must be adjacent to Area 
0. The backbone must be continuous and cannot be partitioned. Area 0 can be extended by 
the use of a virtual link. 


e Nonbackbone, nonstub area— This is a normal OSPF area other than Area O. All LSAs, 
except Type 7, are flooded into this area. 


e Stub area— No external routes are advertised into a stub area, nor will they generate 
external LSA type 5s. A backbone area will advertise a single default route to a stub area or 
a network summary LSA for the destination 0.0.0.0. Some other restrictions on stub areas 


apply: 
- Virtual links cannot be configured across stub areas. 


- Adjacencies will not be established with any other router not configured as a stub, 
except for the Area Border Router. 


- No router within a stub area can be an ASBR because no external routes or LSA 
Type 5 can be advertised out of a stub area. In short, stub areas cannot perform 
redistribution. 


- LSA Types 4 and 5 are blocked into the area. Only LSA Types 1, 2, and 3 are 
flooded into the area. 


e Totally stubby area— Neither external nor internal routes are advertised into this area. LSA 
types 3, 4, and 5 are blocked into the area, except for a single default route advertised as a 
LSA type 3. The router will use the default route to reach any destination outside the area. 


e Not-so-stubby area (NSSAs)— Sometimes, it is necessary to redistribute another routing 
protocol, such as RIP, into a stub area. Because this violates the definition of stub area, a 
new area type was needed. To remedy this, RFC 1587 defines not-so-stubby areas (NSSA). 
An NSSA allows external routes to be advertised into the OSPF domain while retaining the 
other characteristics of a stub area. When external routes are redistributed into a router in 
an NSSA area, the router originates LSA Type 7s to advertise the new external destination(s) 
to routers within the NSSA area. The LSA Type 7s are converted to LSA Type 5 when flooded 
into Area O by the ABR. No LSA type 5s will exist in the NSSA area. All routers in the area 
must be configured NSSA. 


OSPF requires a hierarchical network design through the use of areas controlled by specific router 
types. A router might be multiple router types; for example, ABRs are also backbone routers. The 
OSPF router types are as follows: 


e Internal routers— |nternal routers are routers whose interfaces all reside in the same OSPF 
area. All internal routers have the same SPF database. 


e Area Border Routers (ABRs)— ABRs are routers that connect one or more areas to the 
backbone area. They forward all LSAs from the backbone area. The ABR always has at least 
one interface in Area 0 and keeps a separate SPF database for each area that it is connected 
to. These should be high-end routers for this reason. 


e Backbone routers— These are routers that have at least one interface in Area 0. All 
interfaces might reside in Area 0, in which case the router is an internal backbone router. 


e Autonomous System Boundary Routers(ASBRs)— Routers that redistribute another 
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routing protocol or advertise external routes are called ASBRs. 


The word LSA has been mentioned quite a bit. LSAs are what OSPF uses to build the OSPF database. 
OSPF floods specific LSA types to specific portions of the OSPF domain as dictated by the area and 
router type mentioned previously. LSA are classified by type, and each type serves a specific 
purpose, as described in the following list: 


e Router LSA (Type 1)— This LSA contains information about a router and the links that it 
has in an area. LSA type Is are flooded only in that area. The LSA also tells whether the 
router is a stub or ASBR, or whether it has one end of a virtual link. OSPF represents these 
routes in the forwarding table with an O. 


e Network LSA (Type 2)— This LSA is used for transit networks within an area. It describes 
the set of routers attached to a network. LSA Type 2s are not flooded outside an area. OSPF 
represents these routes in the forwarding table with an O. 


e Summary LSAs for ABRs (Type 3)— These LSAs advertise internal networks to routers in 
other areas, called OSPF interarea routes. The LSA might contain a summary network or a 
single network. ABRs are the only router type that generates this LSA type. OSPF represents 
these routes in the forwarding table with an OIA. 


e Summary LSA for ASBRs (Type 4)— These LSAs are used to advertise the location of an 
ASBR. Routers searching for a path to an external network use LSA Type 4 to determine the 
best next hop. OSPF represents these routes in the forwarding table with an O IA. This LSA 
type is hard to remember, so you can think of it as the "how do | get out here LSA." 


e Autonomous system external LSAs (Type 5)— Type 5 LSAs are used to advertise routes 
redistributed into OSPF. These routes are called OSPF external routes, and they are flooded 
throughout the entire OSPF autonomous system, except for stub, totally stubby, and NSSA 
areas. OSPF represents these routes in the forwarding table with an O E1 or O E2, depending 
on the route. 


e NSSA external LSA (Type 7)— This type of LSA is generated for the external routes 
redistributed into a not-so-stubby area. They are flooded throughout the NSSA area. When 
they hit an ABR, the ABR advertises them as Type 5 LSAs into Area 0. Type 7 LSAs never 
leave the NSSA area. OSPF represents these routes in the forwarding table with an O N1 or 
O N2, depending on how the route was redistributed. 


Table 12-2 summarizes the LSAs that are allowed in each area. 


Table 12-2. LSA Types Allowed in Each Area 


| Area Type | LSA 1 and 2 | LSA 3 and 4 | LSA 5 | LSA 7 
Backbone area (Area 0) ae ae ee 


Stub area 


Totally stubby area ee 
Not- so-stubby area Yes Yes Yes 
[Nonbackbone, nonstub area Yes Yes INo 


[“] One LSA Type 3 is used to advertise the default route 
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NOTE 


RFC 2370 defines opaque link states. Opaque LSAs are Type 9, 10, and 11 link-state 
advertisements. These advertisements might be used directly by OSPF or indirectly by 
some application wanting to distribute information throughout the OSPF domain, such 
as RSVP. The function of the opaque LSA option is to provide for future extensibility of 
OSPF. The following section is taken directly from RFC 2370: 


3.0 The Opaque LSA 


Opaque LSAs are types 9, 10 and 11 link-state advertisements. Opaque LSAs consist of 
a standard LSA header followed by a 32-bit aligned application-specific information 
field. Standard link-state database flooding mechanisms are used for distribution of 
Opaque LSAs. The range of topological distribution (i.e., the flooding scope) of an 
Opaque LSA is identified by its link-state type. This section documents the flooding of 
Opaque LSAs. 


The flooding scope associated with each Opaque link-state type is defined as follows. 


Link-state type 9 denotes a link-local scope. Type-9 Opaque LSAs are not flooded 
beyond the local (sub)network. 


Link-state type 10 denotes an area-local scope. Type-10 Opaque LSAs are not flooded 
beyond the borders of their associated area. 


Link-state type 11 denotes that the LSA is flooded throughout the Autonomous System 
(AS). The flooding scope of type-11 LSAs are equivalent to the flooding scope of AS- 
external (type-5) LSAs. Specifically type-11 Opaque LSAs are 1) flooded throughout all 
transit areas, 2) not flooded into stub areas from the backbone and 3) not originated 
by routers into their connected stub areas. As with type-5 LSAs, if a type-11 Opaque 
LSA is received in a stub area from a neighboring router within the stub area the LSA is 
rejected. 


Figure 12-6 illustrates a modern OSPF network, highlighting the different router types. 


Figure 12-6. OSPF Network Router types 


747 


Autonomous System Boundary Router 
(ASBR) 


ee ee ee ee eee 


<———— Interior routers 


I 


Area Border 


he ee ee ee snail | 


ewreeeerer er ere2 


+ ~ 


' 
' 
t 
' 
' 
' 


,% 
os 
| 


OSPF Acknowledgments 


To ensure that LSAs are transmitted successfully, OSPF requires each LSA to be acknowledged. LSAs 
are acknowledged by one of the following acknowledgment types: 


e Implicit acknowledgment— Occurs when the sending router receives a duplicate LSA from 
the neighbor. By seeing the neighbor report the LSA, the router knows "implicitly" that it 
received the LSA. 


e Explicit acknowldgment— Requires the receiving router(s) to send a specific link-state 
acknowledgement packet in response to the LSA. 


To ensure that LSAs are current and valid, each LSA has a sequence number, a checksum, and a 
MaxAge value. The sequence number and checksum verify that the LSA is valid, whereas the age 
parameter ensures that the LSA is the most current LSA. MaxAge is used to verify how old the LSA 
was. MaxAge is set for 3600 seconds, or 1 hour. When a router originates an LSA, it sets the 
MaxAge at 0. Each time the LSA is flooded by another router, its MaxAge is incremented by another 
timer called InffransDelay, which has a default value of 1. When the LSA reaches the MaxAge value, 
the LSA is reflooded throughout the network. Routers also use the MaxAge parameter when 
comparing two LSAs to determine which one is more current. This type of flooding can be excessive 
on large stable networks. In Cisco |OS 12.1, Cisco introduced a concept called LSA flooding 
reduction. LSA flooding control is discussed more in upcoming sections. 


OSPF Path Types 


When you perform the show ip route command on OSPF, each route is classified in OSPF as one of 
six path types. The path is preceded by a tag representing the route's type. The path types and tags 
used are as follows: 


e (O) Intra-area paths/ routes— These are routes to networks within the same OSPF area. 
e (O1A) Interarea paths/ routes— These are routes to networks in different OSPF areas but 


within the same OSPF autonomous system. 
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e (O€E1) External Type 1 paths/ routes— When an external route is redistributed into 
OSPF, it must be assigned a metric or cost. Type 1 paths have a cost that is the sum of this 
external path/metric plus the internal cost of the path to the ASBR reporting the route. 


e (OE2) External Type 2 paths/ routes— This is the same as a Type 1 route, except for the 
fact that the internal cost to the ASBR is not added to the default cost of the path. By 
default, all routes distributed into OSPF become external Type 2 routes. This can be changed 
during redistribution. 


e (ON1) OSPF NSSA type 1— When an external route is redistributed into an OSPF NSSA 
area, it becomes this type. Type 1 paths have a cost that is the sum of this external path/ 
metric plus the internal cost of the path to the router reporting the route. 


e (ON2) OSPF NSSA type 2— This is the same as a Type 1 route, except that the internal 
cost to the router is not added to the default cost of the path. By default, all routes 
distributed into OSPF NSSA area become OSPF NSSA external Type 2 routes. This can be 
changed during redistribution. 


Example 12-2 lists a complex route table with four types of OSPF routes. 


Example 12-2 Complex OSPF Route Table 


skynet#show ip route 
Codes: C -—- connected, S - static, I - IGRP, R -—- RIP, M —- mobile, B - BGP 
D —- EIGRP, EX -— EIGRP external, O - OSPF, IA — OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * -— candidate default 
U - per-user static route, o - ODR 


Gateway of last resort is 172.16.128.1 to network 0.0.0.0 


10.0.0.0/24 is subnetted, 1 subnets 


O 10.10.10.0 is a summary, 03:05:49, Null0O 
129.201.0.0/24 is subnetted, 1 subnets 
O BL 129.201.1.0 [110/90] via 172.16.2.66, 03:05:45, TokenRingl 


128.200.0.0/24 is subnetted, 1 subnets 
D EX 128:.200.1.,0 [270/6799360]. Via T7216 .192.3, OS:42¢57; Sexrvali 
129.200.0.0/24 is subnetted, 1 subnets 


O El 129.200.1.0 [110/90] via 172.16.2.66, 03:05:45, TokenRingl 
128.201.0.0/24 is subnetted, 1 subnets 

D EX 128.201.1120 [170/679936] via. 172.16.192.3,. 05242257, Seriall 

Cc 201.201.101.0/24 is directly connected, Loopback0O 

O E2 132.31.0.0/16 [110/2] via 172.16.2.66, 00:58:04, TokenRingl 

O BE2 131.31.0.0/16 [110/2] via 172.16.2.66, 00:58:04, TokenRingl 
172.16.0.0/16 is variably subnetted, 27 subnets, 4 masks 

O IA 172.16.152.0/24 [110/71] via 172.16.2.66, 03:05:45, TokenRingl 

O IA 172.16.150.0/24 [110/80] via 172.16.2.66, 03:05:45, TokenRingl 

O IA 172.16.151.0/24 [110/71] via 172.16.2.66, 03:05:45, TokenRingl 

Cc 172.16.144.0/21 is directly connected, Loopback20 

Cc 172.16.136.0/21 is directly connected, Ethernet1l 

Cc 172.16.128.0/21 is directly connected, Ethernet0 

Cc 172.16.220.0/24 is directly connected, Loopback69 

Cc 172.16.192.0/24 is directly connected, Seriall 

Cc 172.16.192.3/32 is directly connected, Seriall 

O IA 172.16.42.2/32 [110/70] via 172.16.2.66, 03:05:46, TokenRingl 

O IA 172.16.42.3/32 [110/70] via 172.16.2.66, 03:05:46, TokenRingl 

O E2 172.16.42.0/24 [110/2] via 172.16.2.66, 03:05:46, TokenRingl 

O IA 172.16.42.1/32 [110/6] via 172.16.2.66, 03:05:46, TokenRingl 
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IA 172.16.21.0/24 [110/76] via 172.16.2.66, 03:05:46, TokenRingl 
IA 172.16.22.0/24 [110/71] via 172.16.2.66, 03:05:46, TokenRingl 
E2 172.16.1.0/24 [110/2] via 172.16.2.66, 03:05:46, TokenRingl 
E2 172.16.2.0/24 [110/2] via 172.16.2.66, 03:05:46, TokenRingl 


172.16.102.0/24 [90/679936] via 172.16.192.3, 05:42:59, Seriall 
172.16.103.0/24 [90/409600] via 172.16.128.1, 05:42:59, Ethernet0O 


OOOO C'O'R OOo © © 


E2 172.16.84.0/24 [110/2] via 172.16.2.66, 03:05:47, TokenRingl 
E2 172.16.85.0/24 [110/2] via 172.16.2.66, 03:05:47, TokenRingl 
E2 172.16.81.0/24 [110/2] via 172.16.2.66, 03:05:47, TokenRingl 
E2 172.16.82.0/24 [110/2] via 172.16.2.66, 03:05:47, TokenRingl 
E2 172.16.83.0/24 [110/2] via 172.16.2.66, 03:05:47, TokenRingl 
E2 172.16.64.0/24 [110/2] via 172.16.2.66, 03:05:47, TokenRingl 


<<<text omitted>>> 


This section on the technical aspects of OSPF is meant to give you a solid background on OSPF 
fundamentals so that the configuration commands will have a firmer meaning when used. Several 
books have been written on OSPF describing in further detail OSPF packet structure, as well as other 
OSPF intricacies. For further reading, we suggest J eff Doyles's Routing TCP/IP, Volume 1; Tom 
Thomas's OSPF Network Design Solutions; and John Moy's OSPF, Anatomy of an Internet Routing 
Protocol. The Cisco OSPF design guide on www.cisco.com and RFC 2328 also make good references. 
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Configuring OSPF 


Unlike other routing protocols, OSPF requires a certain amount of predesign before implementation. 
Careful consideration must be applied to the OSPF network as a whole, not just a single area. The 
following list contains some design considerations that you should take into account when deploying 
OSPF: 


e Area deployment— Area 0 must be continuous and should be located in the most stable 
part of the network. This usually consists of the core routers. 


e Router I Ds— Statically configure router ID (RIDs). Use the private subnet of 192.168.0.0 to 
accomplish this. Remember, the highest addresses become the DR and the BDR. Cisco |OS 
Level 12.0 and above allow for static RIDs without having to use loopback interfaces. 


e RIDs and priority used to "hard-code" DR and BDR— Where the OSPF network type 
requires the use of a DR and BDR, use OSPF priority or router IDs to force the election of the 
DR and BDR. The DR on Frame Relay networks should be the router with a direct PVC to all 
the neighbors in that area. On LANs, the DR and BDR should be the higher-end routers. 


e Continuous IP addressing within an area— When possible, all addresses in an area 
should be continuous. This leads toward route summarization and a natural hierarchical 
design. 


e Various forms of Stub areas— Many edge routers and Frame Relay networks lead nicely 
toward the use of stub areas. Use the different forms of stub areas whenever possible. 


e Virtual links avoided— Even though we will discuss virtual links, their deployment and 
presence is an indication of poor network design. There are a few cases in which backup links 
might not be directly connected to Area 0, and a virtual link will be needed. Overall, they 
should be avoided in production networks. 


With these design considerations in mind, you will use the following seven-step task list to configure 
OSPF: 


Step 1. Divide the OSPF network into various areas by using the design guidelines 
listed previously. Make a network diagram, and highlight Area 0, other areas, and the area 
types. If the network will be using a DR/BDR, mark which routers will serve that function. 


Step 2. (Optional) Assign permanent router | Ds to the network. To accomplish this, 
configure loopback interfaces for use as static RIDs, if on Cisco |OS Software earlier than 
Release 12.0. The loopback interfaces should be in a high private address space and do not 
need to be advertised by OSPF. We recommend using the range 192.168.x.x. on loopback 
interface 0. If the OSPF network type will elect a DR/BDR, such as in an Ethernet network, 
assign the routers to be the DR and BDR the higher IP addresses, such as 192.168.250.251 
and 192.168.250.250. RIDs can be assigned in Cisco |OS Software 12.0 and above with the 
OSPF router command router-id ip_ address. Note: OSPF must be enabled before the 
router 1D can be assigned. 


Step 3. Enable OSPF on the router and configure RI Ds. This is accomplished with the 
router ospf process_id global command. | like to think of the process_id as an 
Autonomous System ID. This number should be the same on all routers within the 
autonomous system. This is not a technical requirement, but a suggestion for network 
documentation. The process ID is only used internally by the router. At this time, also 
configure the RIDs that you assigned in Step 2. Use the router command router-id 

ip_ address. 


Step 4. Configure interfaces to participate in OSPF. The OSPF uses a network 
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statement that is followed by a wildcard mask and an area ID. 


network a.b.c.d wildcard_mask area X 


A wildcard mask can be considered an inverse bit mask, where the 0 bit is a "care" bit, anda 
1 bit is a "don't care" bit. For example, to run OSPF only on networks 128.10.1.0/24 to 
128.10.255.0/24 in Area 0, the syntax would resemble this: 


network 128.10.0.0 0.0.255.255 area 0 


For another example, to run OSPF only on the network 172.16.128.4/30 in Area 100, the 
syntax would resemble this: 


network 172.16.128.4 0.0.0.3 area 100 


Use a wildcard mask of 0.0.0.0 to enable OSPF on a single interface. Use the tightest 
wildcard mask possible when configuring OSPF. This will prevent OSPF from advertising 
networks that you might be unaware of. It also prevents unnecessary OSPF hellos from 
entering those segments. 


Step 5. Configure OSPF neighbor support. The OSPF network type might require 
additional configuration for OSPF to build an adjacency. On NBMA networks, such as Frame 
Relay, the OSPF configuration will be interface-dependant. Table 12-3 highlights some 


common network types and tells whether any additional configuration is needed. 


Table 12-3. OSPF Network Configuration Table 


Default 

Physical | OSPF Desired 

Interface [Network |Neighbor Neighbor Priority 
Type Needed |Elected| State | Recommended 


Broadcast |Broadcast |No FULL/DR Yes 
media 
Ethernet, FULL/BDR 


FULL/— 


Yes FULL/ No 
DROTHER 
natural or 
multipoint 
Point-to- No ~ No 
Point-to- |No No FULL/— No 
multipoint 


[“] | the OSPF network type on a Frame Relay network is changed to 752 


BROADCAST, it will have a DR and BDR election and priority should be set. 


[“] The OSPF network type of point-to-multipoint is not the default network type of 
any interface. OSPF point-to-multipoint networks must be statically configured. 


When configuring OSPF over Frame Relay multipoint interfaces, it is necessary to configure static 
neighbors. Without the neighbor statements, the router's neighbor will be in a constant state of 
waiting and will never form an adjacency. To configure the static neighbor, use this OSPF router 
command: 


Router (config-route) neighbor ip_address_of_neighbor 


The hub router of the multipoint network, or the router that has a PVC to each site, should be 
statically configured as the DR. To accomplish this, set the priority of the spoke or remote routers to 
0. A priority of 0 tells OSPF that this interface or neighbor will not participate in the DR/BDR election 
process. The DR choice can be further influenced by configuring the priority of the link on the router 
of the DR to the high number, such as 255. The priority can be configured with this interface 
command: 


Router (config-if)ip ospf priority 0-255 


The default OSPF priority is 1. 


Another way to force an adjacency creation is simply to change the OSPF network type to something 
more desirable. Changing a Frame Relay multipoint network to a point-to- multipoint will make OSPF 
treat the multipoint network like many point-to-point networks. Changing the network type to 
broadcast also forces adjacency creation and DR/BDR election. To change the OSPF network type, 
use the following interface command: 


Router (config-if) ip ospf network [broadcast | non-broadcast | 
point-—to-multipoint | point-to-point ] 


Step 6. (Optional) Configure OSPF special area types. To configure OSPF areas as 
stubs, NSSAs, and totally stubby areas, use the following OSPF router command: 


Router (config-route)area x [nssa | stub | virtual-link ] [no-summary] 


To configure an area as a stub or an NSSA area, simply add the area command followed by 
this parameter. For example, to configure Area 10 as a stub, the syntax would resemble this: 


Router (config-route) area 10 stub 


A totally stubby area is configured by configuring a normal stub area followed by the no- 
summary argument to block LS Types 3 and 4. 


Router (config-route) area 10 stub no-summary 


Step 7. (Optional) Configure any optional OSPF parameters. These include such things 
as hello timers, route summarization, authentication, and so on. These and other OSPF 
optional parameters are discussed in upcoming sections. 


Practical Example: Configuring Multiple OSPF Area Types over Frame Relay 


To better understand this rather lengthy process, let's apply it to an practical example. Figure 12-7 


illustrates an OSPF network that is in Step 1 of the configuration process. This model of OSPF has a 
Frame Relay multipoint and point-to-point network. You will be configuring a totally stubby area, 
Area 100, for the luke router. The paul router will reside in Area 0, the backbone area, along with 
the Ethernet interface of the router john. The mark and mathew routers will be in OSPF Area 10. We 
have marked john to be the DR for the WAN and LAN networks. 


Figure 12-7. OSPF Multiple-Area Network 
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Step 2 calls for defining or configuring RIDs. In this particular network, only the mathew router is 
running a version of Cisco |OS Software prior to Release 12.0, so it will have to use a loopback 
address to configure a RID. Recall that OSPF will use the highest loopback address for a RID; this is 
why this step precedes enabling OSPF. On the mathew router, create a static RID with the following 
commands: 


mathew(config) #int loop 0 
mathew(config-if) #ip address 172.16.250.1 255.255.255.0 


Figure 12-8 illustrates the RIDs used in this model. It should be noted that this step is optional but 
recommended for stability reasons. 


Figure 12-8. OSPF Static RIDs 
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When configuring OSPF in a lab scenario, we assign our RIDs so that the last octet of 
the RID is the router number. For example, if you have the routers R1, R2 and R3, you 
would assign the RIDs to be 192.168.250.1, 192.168.250.2, and 192.168.250.3, 
respectively. The DR in the lab has an unusually high RID, 250, so it stands out from 
the rest. When viewing the OSPF database, having RIDs that somewhat "self- 
document" the network can be a great benefit. 


Step 3 involves enabling the OSPF process and configuring RIDs. The OSPF autonomous system is 7, 
so you will use 7 as the OSPF process ID. During this step, you also will configure the RIDs with the 
router command router-id ip address. Example 12-3 demonstrates this step on the mark and john 


routers. 


Example 12-3 Enabling OSPF on mark and john 


mark (config) #router ospf 7 
mark (config-router) #router-id 192.168.250.6 


john (config) #router ospf 7 
john (config-router) #router-id 192.168.250.250 


After the OSPF process is enabled on all the routers, Step 4 requires that you configure the 
interfaces or networks participating in OSPF. Using the router command network ip_address 
wildcard_mask area x, you define the networks to run OSPF and also specify the area that those 
networks will reside in. Example 12-4 demonstrates the configuration of network statements on the 


router john. 
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Example 12-4 Configuring OSPF on the Router john 


john (config) #router ospf 7 

john (config-router) #network 172.16.9.0 0.0.0.255 area 0 
john (config-router) #network 172.16.1.0 0.0.0.255 area 10 
john (config-router) #network 172.16.2.4 0.0.0.3 area 100 


You can configure the network statements on the remaining routers in many ways. We personally 
prefer limiting the network statement with a specific wildcard mask to one network per statement, 
or to a single interface with the 0.0.0.0 as the wildcard mask. In large networks, this type of 
configuration might be less desirable, and you might want to use a single network statement to 
group multiple interfaces into the same OSPF area. However, if you add new interfaces and they 
must go into different areas, you will have to remove the network statement and add it again for 
the new network statement to take effect. 


At this point during the configuration, OSPF builds adjacencies on the Frame Relay point-to-point 
network between john and luke. Another adjacency is built on the Ethernet network between john 
and paul. OSPF, however, will not be capable of building an adjacency on the Frame Relay 
multipoint network between john, mark, and mathew without additional configuration. You can 
verify adjacency formation by performing a show ip ospf neighbor command on the router john, 
as in Example 12-5. The show and debug commands for OSPF are discussed in the next section. 


Example 12-5 show ip ospf neighbor Performed on the Router john 


john#show ip ospf neighbor 


Neighbor ID Pra State Dead Time Address Interface 
192). 168.25 0:.9 ap FULL/BDR 00:00:34 V2 LO De 9 Ethernet0 
LO? LOSa 250. <3 if FULL/ - 00:00:38 ay preety Se ara Serial0.2 
john# 


Notice how clearly the router |Ds show up in the previous command. This can significantly help 
troubleshooting OSPF on any size network. 


Step 5 calls for the configuration of additional neighbor support to remedy the adjacency situation 
between john, mark, and mathew. Because you took the extra time to hard-code RIDs on all the 
routers, the john router will be DR for the connected LAN and WAN interfaces. You will take this a 
step further when defining neighbor statements. For the router john to build an adjacency with 
mark and mathew, you will need to add neighbor statements to all the routers. By setting the OSPF 
priority to 0 on the interface, that router will never participate in DR/BDR election. On multipoint 
networks, only the routers that have PVCs to all remote locations should be eligible for DR/BDR 
election. The default priority of 1 will be sufficient on the neighbor statements of the mark and 
mathew routers that point toward john. Example 12-6 illustrates the relevant portions of the OSPF 


configuration, to this point, on john, mark, and mathew, respectively. 


Example 12-6 OSPF Configuration of john, mark, and mathew Routers 


hostname john 
! 
interface Serial0O.1 multipoint 
ip address 172.16.1.5 255.255.255.0 
no ip directed-broadcast 
~~ Set this routers priority to 255, forcing the DR 
frame-relay map ip 172.16.1.6 121 broadcast 
frame-relay map ip 172.16.1.1 111 broadcast 
! 
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interface Serial0.2 point-to-point 

ip address 172.16.2.5 255.255.255.252 
no ip directed-broadcast 

frame-relay interface-dlci 150 

! 
router ospf 7 

router-id 192.168.250.250 

network 172.16.1.0 0.0.0.255 area 10 
network 172.16.2.4 0.0.0.3 area 100 
network 172.16.9.0 0.0.0.255 area 0 


hostname mark 

! 

interface Serial0 

ip address 172.16.1.6 255.255.255.0 
no ip directed-broadcast 
encapsulation frame-relay 


’'This router will not participate in DR/BDR election 
no ip mroute-cache 


frame-relay map ip 172.16.1.5 102 broadcast 
frame-relay map ip 172.16.1.1 102 broadcast 
! 
router ospf 7 

router-id 192.168.250.6 

network 172.16.1.0 0.0.0.255 area 10 
network 172.16.5.0 0.0.0.255 area 10 


neighbor 172.16.1.5 
! 


hostname mathew 

! 

interface Serial0 

ip address 172.16.1.1 255.255.255.0 
encapsulation frame-relay 


no ip mroute-cache 


frame-relay map ip 172.16.1.5 110 broadcast 
frame-relay map ip 172.16.1.6 110 broadcast 
! 
router ospf 7 

network 172.16.1.0 0.0.0.255 area 10 
network 172.16.10.0 0.0.0.255 area 10 


neighbor 172.16.1.5 
! 


By adding the neighbor statements, OSPF now builds adjacencies over the Frame Relay multipoint 
network. This can be verified by performing the show ip ospf neighbor command on the router 
john. Example 12-7 demonstrates this command on john. 


Example 12-7 show ip ospf neighbor Command Output for Router john 


john#show ip ospf neighbor 


Neighbor ID Pra State Dead Time Address Interface 


1925,.1:68'5250' 9 1, FULL/BDR 0000332 VIA6 163.9369 Ethernet0 757 


LIZ 16.2090. 2 0 FULL/DROTHER OOTOLESS VITA sdG< 1.1 Serial0.1 


192.168.250.6 0 FULL/DROTHER 00:01:46 172 216.1 «6 Serial0d.1 
192.168.2503 1 FULL/ - 00:00:37 72. 1 6:..2:.6 Serial0.2 
john# 


The mathew and mark routers will not become adjacent with each other because there is not a 
direct connection between them. Example 12-8 shows the active neighbor on the mathew router. 
The adjacency is in a FULL state, with john being the DR for the link. 


Example 12-8 show ip ospf neighbor Command Output for Router mathew 


mathew#show ip ospf neighbor 


Neighbor ID Pra State Dead Time Address Interface 
LIZ N6S.250 2250 255 FULL/DR 00:01:48 IZ Led sid Serial0 
mathew# 


You could accomplish this in other ways without using neighbor commands. Another way is to 
change the OSPF network type to either broadcast or point-to-multipoint. Technically, a point-to- 
multipoint would be a more accurate network type to use. Configuring the same network model, you 
will now use the network type of point-to-multipoint to create adjacencies between mathew, mark, 
and john. Example 12-9 lists the relevant configuration of the john and mathew routers, using the 
ip osfp network type command in place of neighbor statements. The configuration of mark would 
be identical to that of mathew. 


Example 12-9 Configuration of john and mark Using Network Types 


hostname john 

! 

interface Serial0 

no ip address 

no ip directed-broadcast 
encapsulation frame-relay 

no ip mroute-cache 

! 

interface Serial0O.1 multipoint 
ip address 172.16.1.5 255.255.255.0 
no ip directed-broadcast 


_ip ospf network point-to-multipoint  -««* Change the default OSPF network type 
ESrEas 


— 


frame-relay map ip 172.16.1.6 121 broadcast 
frame-relay map ip 172.16.1.1 111 broadcast 
! 
router ospf 7 

router-id 192.168.250.250 

network 172.16.1.0 0.0.0.255 area 10 
network 172.16.2.4 0.0.0.3 area 100 


“network 172.16.9.0 0.0.0.255 area 0 ==” No neighbors 
! 


hostname mathew 

! 

interface Serial0O 

ip address 172.16.1.1 255.255.255.0 
encapsulation frame-relay 
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no ip mroute-cache 

frame-relay map ip 172.16.1.5 110 broadcast 
frame-relay map ip 172.16.1.6 110 broadcast 
! 
router ospf 7 

network 172.16.1.0 0.0.0.255 area 10 


network 172.16.10.0 0.0.0.255 area 10 
! 


Example 12-10 lists how the neighbors look on the mathew and john routers. 


Example 12-10 OSPF Neighbors on mathew and john 


mathew#show ip ospf neighbor 


Neighbor ID Pra State Dead Time Address Interface 
192.168 <2500250 al FULL/ - 0001335 LIZ 5 VO oS Serial0d 
mathew# 


john#show ip ospf neighbor 


Neighbor ID Pra State Dead Time Address Interface 
192. 168..250).9 if FULL/BDR 00: 00736 LIA eL 6399 Ethernet0 
172;,16.250:,,2 1 FULL/ - 00:01:58 VID ll Gisele oD Serial0d.1 
192.168:..250'.:6 1 FULL/ - 00201258 LT2 sO 2.6 Serial0.1 
192.1 68.;250'53 i FULL/ - 00:00:38 Ug 2s elle cone reo! Serial0.2 


john# 


Steps 6 and 7 in the OSPF configuration process are optional; they involve configuring any OSPF 
area types and any other OSPF enhancements. In this model, you need only to configure one more 
step, and that is to configure the router luke to be in a totally stubby area. To configure a totally 
stubby area, the area needs to first be configured as a stub area, and then the argument no- 
summary must be used. The syntax will resemble the following: 


area 100 stub no-summary 


These commands should be added to the john and luke routers. Example 12-11 lists the output of 
the show ip ospf and show ip route command on the router luke. 


Example 12-11 Verifying the Totally Stubby Area on luke 


luke# show ip ospf 7 
Routing Process "ospf 7" with ID 192.168.250.3 
Supports only single TOS(TOSO) routes 
Supports opaque LSA 
SPF schedule delay 5 secs, Hold time between two SPFs 10 secs 
Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs 
Number of external LSA 0. Checksum Sum 0x0 
Number of opaque AS LSA 0. Checksum Sum 0x0 
Number of DCbitless external and opaque AS LSA 0 
Number of DoNotAge external and opaque AS LSA 0 
Number of areas in this router is 1. 0 normal 1 stub O nssa 
External flood list length 0 
Area 100 
Number of interfaces in this area is 2 
It is a stub area, no summary LSA in this area 
Area has no authentication 


SPF algorithm executed 46 times 
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Area ranges are 

Number of LSA 3. Checksum Sum 0x16F14 

Number of opaque link LSA 0. Checksum Sum 0x0 
Number of DCbitless LSA 0 

Number of indication LSA 0 

Number of DoNotAge LSA 0 

Flood list length 0 


luke#show ip route 
Codes: C —- connected, S - static, I - IGRP, R - RIP, M —- mobile, B - BGP 
D — EIGRP, EX -—- EIGRP external, O - OSPF, IA — OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i = S=1S),. “Tdi IS-IS level-1, L2 IS-IS level-2, ia -— IS-IS inter area 
* — candidate default, U - per-user static route, o - ODR 
P -— periodic downloaded static route 


Gateway of last resort is 172.16.2.5 to network 0.0.0.0 


172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks 


Cc 172.16.2.4/30 is directly connected, Serial0d.1 

ic 172.16.3.0/24 is directly connected, TokenRing0O 
OFFA 0.0,0,0/0 [110/65] via 172.16.2.5, 00:02:23, Seriald,1 
luke# 


Instead of a full routing table, the luke router will receive only a default route from john, as shown 
in Example 12-12. 


Example 12-12 shows the relevant portions of the configurations and the route tables used in this 
model. 


Example 12-12 Configurations and Route Table of john, mark, mathew, 
luke, and paul 


! 
hostname john 
! 
interface Ethernet0O 
ip address 172.16.9.5 255.255.255.0 
no ip directed-broadcast 
! 
interface Serial0 
no ip address 
no ip directed-broadcast 
encapsulation frame-relay 
no ip mroute-cache 
! 
interface Serial0.1 multipoint 
ip address 172.16.1.5 255.255.255.0 
no ip directed-broadcast 
ip ospf network point-—to-multipoint 
frame-relay map ip 172.16.1.6 121 broadcast 
frame-relay map ip 172.16.1.1 111 broadcast 
! 
interface Serial0.2 point-to-point 
ip address 172.16.2.5 255.255.255.252 
no ip directed-broadcast 
frame-relay interface-dlici 150 
! 
router ospf 7 
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router-id 192.168.250.250 
area 100 stub no-summary 
network 172.16.1.0 0.0.0.255 area 10 
network 172.16.2.4 0.0.0.3 area 100 
network 172.16.9.0 0.0.0.255 area 0 


john# 
john#show ip route 
Codes: C -—- connected, S - static, I - IGRP, R -—- RIP, M —- mobile, B - BGP 
D —- EIGRP, EX -— EIGRP external, O - OSPF, IA — OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 -— IS-IS level-2, ia - IS-IS inter area 
* — candidate default, U - per-user static route, o - ODR 
P — periodic downloaded static route 


Gateway of last resort is not set 


172.16.0.0/16 is variably subnetted, 8 subnets, 4 masks 


Cc 172.16.9.0/24 is directly connected, Ethernet0O 

©) 172.16.10.0/29 [110/74] via 172.16.1.1, 00:16:06, Serial0O.1 
O 172.1635.0/24 [110/74] via 172.16.1.6, 00216706, Serial0.i 
Cc 172.16.2.4/30 is directly connected, Serial0.2 

©) 172.16.1.6/32 [110/64] via 172.16.1.6, 00:16:06, Serial0.1 
) VI72216.1.,1/32- [110/64] via L72e16.1.1, 00216706, Seriald.1 
Cc 172.16.1.0/24 is directly connected, Serial0d.1 

) 172.16.3.0/24 [110/70] via 172.16.2.6, 00:13:47, Serial0.2 
john# 


! 
hostname mark 
! 
interface Ethernet0O 
ip address 172.16.5.5 255.255.255.0 
no ip directed-broadcast 
! 
interface Serial0 
ip address 172.16.1.6 255.255.255.0 
no ip directed—-broadcast 
encapsulation frame-relay 
ip ospf network point—-to-multipoint 
no ip mroute-cache 
frame-relay map ip 172.16.1.5 102 broadcast 
frame-relay map ip 172.16.1.1 102 broadcast 
! 
router ospf 7 
router-id 192.168.250.6 
network 172.16.1.0 0.0.0.255 area 10 
network 172.16.5.0 0.0.0.255 area 10 
! 
mark# 
mark#show ip route 
Codes: C connected, S static, I - IGRP, R - RIP, M — mobile, B —- BGP 
D -— EIGRP, EX -— EIGRP external, O - OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i = ES=1S;, Lil IS-IS level-1, L2 IS-IS level-2, ia -—- IS-IS inter area 
* — candidate default, U - per-user static route, o - ODR 
P — periodic downloaded static route 


Gateway of last resort is not set 
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172.16.0.0/16 is variably subnetted, 8 subnets, 4 masks 


O IA 172.16.9.0/24 [110/74] via 172.16.1.5,; 00:29:30, Seriald 

O 172.16.10.0/29 [110/138] via 172.16.1.5, 00:29:30, Serial0d 
O 172.16.1.5/32 [110/64] via 172.16.1.5, 00:29:30, Seriald 
Cc 172.16.5.0/24 is directly connected, Ethernet0O 

O IA 172.16.2.4/30 [110/128] via 172.16.1.5, 00:29:30, SerialO 
O 172,16.141/32 [110/128] via 172.16.125, 00229530, Seriald 
Cc 172.16.1.0/24 is directly connected, Serial0O 

O IA 172.16.3.0/24 [110/134] via 172.16.1.5, 00:15:36, Seriald 
mark# 

mark# 


hostname mathew 
! 
interface Loopback0O 
ip address 172.16.250.1 255.255.255.0 
! 
interface Ethernet2 
ip address 172.16.10.1 255.255.255.248 
media-type 10BaseT 
! 
interface Serial0 
ip address 172.16.1.1 255.255.255.0 
encapsulation frame-relay 
ip ospf network point-to-multipoint 
no ip mroute-cache 
frame-relay map ip 172.16.1.5 110 broadcast 
frame-relay map ip 172.16.1.6 110 broadcast 
! 
router ospf 7 
network 172.16.1.0 0.0.0.255 area 10 
network 172.16.10.0 0.0.0.255 area 10 
! 
mathew# 
mathew#show ip route 
Codes: C connected, S static, I - IGRP, R - RIP, M — mobile, B —- BGP 
D -— EIGRP, EX —- EIGRP external, O - OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * -— candidate default 
U - per-user static route, o - ODR 


Gateway of last resort is not set 


172.16.0.0/16 is variably subnetted, 9 subnets, 4 masks 


Cc 172.16.250.0/24 is directly connected, Loopback0 

O IA 172.16.9.0/24 [110/74] via 172.16.1.5, 00:29:44, Serial0d 
Cc 172.16.10.0/29 is directly connected, Ethernet2 

) 172.16.1.5/32 [110/64] via 172.16.1.5, 00:29:44, Serial0d 
O 172.16.5.0/24 [110/138] via 172.16.1.5, 00:29:44, Serial0O 
O IA 172.16.2.4/30 [110/128] via 172.16.1.5, 00:29:44, Serial0 
O 172.16.1.6/32 [110/128] via 172.16.1.5, 00:29:44, Serial0d 
ee 172.16.1.0/24 is directly connected, Serial0O 

O IA 172.16.3.0/24 [110/134] via 172.16.1.5, 00:15:54, Serial0 
mathew# 

mathew# 


hostname luke 
! 


interface SerialO 
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no ip address 
no ip directed-broadcast 
encapsulation frame-relay 
no ip mroute-cache 
frame-relay lmi-type cisco 
! 
interface Serial0.1 point-to-point 
ip address 172.16.2.6 255.255.255.252 
no ip directed-broadcast 
frame-relay interface-dlci 151 
! 
router ospf 7 
router-id 192.168.250.3 
area 100 stub no-summary 
network 172.16.2.4 0.0.0.3 area 100 
network 172.16.3.0 0.0.0.255 area 100 
! 
luke# 
luke#show ip route 
Codes: C connected, S static, I - IGRP, R - RIP, M — mobile, B —- BGP 
D -— EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
1 = TS=1S, Li IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area 
* — candidate default, U - per-user static route, o -— ODR 
P — periodic downloaded static route 


Gateway of last resort is 172.16.2.5 to network 0.0.0.0 


172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks 


Cc 172.16.2.4/30 is directly connected, Serial0d.1 

C 172.16.3.0/24 is directly connected, TokenRing0 
O*FIA 0.0.0.0/0 [110/65] via 172.16.2.5, 00:14:56, Seriald.1 
luke# 

luke# 


! 
hostname paul 
! 
interface Ethernet0/0 
ip address 172.16.9.9 255.255.255.0 
no ip directed-broadcast 
! 
router ospf 7 
router-id 192.168.250.9 
network 172.16.9.0 0.0.0.255 area 0 
! 
paul# 
paul# 
paul#show ip route 
Codes: C - connected, S - static, I - IGRP, R -—- RIP, M —- mobile, B - BGP 
D —- EIGRP, EX -— EIGRP external, O - OSPF, IA — OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U - per-user static route, o - ODR 


Gateway of last resort is not set 


172.16.0.0/16 is variably subnetted, 8 subnets, 4 masks 
Cc 172.16.9.0/24 is directly connected, Ethernet0/0 
O IA 172..16.10.0/29 [110/84] via 172.16.9.5, O0s30232, Bthernetd/0 
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O IA 172.16.1.5/32 [110/10] via 172.16.9.5, 00:31:27, Ethernet0/0 
O IA 172.16.5.0/24 [110/84] via 172.16.9.5, 00:30:42, Ethernet0/0 
O IA 172.16.2.4/30 [110/74] via 172.16.9.5, 00:31:27, Ethernet0/0 
O IA 172.16.1.6/32 [110/74] via 172.16.9.5, 00:30:42, Ethernet0/0 
O IA 172.16..1.1/32 [110/74] via 172.16.9.5, 00230:32, Ethernetd/0 
O IA 172.16.3.0/24 [110/80] via 172.16.9.5, 00:16:41, Ethernet0/0 
paul# 


Before further discussing these and other OSPF configuration options, let's take a closer look at the 
"Big show" and "Big D" commands for OSPF. 
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The "Big show" and "Big D" for OSPF 


Like most routing protocols, Cisco provides a vast array of show and debug commands to 
aid in the verification of OSPF. In practical application, a majority of OSPF problems and 
information can be gained from three primary commands: 


show ip ospf database 
show ip ospf neighbors 
debug ip ospf adj 


Like EIGRP, one of the best and most overlooked commands is show ip ospf neighbors. 
Cisco also offers a way to examine the OSPF database, as well as providing detailed OSPF 
adjacency information. 


The following list shows the complete syntax for what we find to the most useful show, 
debug, and logging commands for OSPF as detailed in upcoming sections: 


show ip ospf neighbors [detail | interface_name] 
show ip ospf [process-id area-id] database 

show ip ospf interface [interface_type ] 

show ip route 

show ip ospf [process_id] 

debug ip ospf adj 

debug ip ospf events 

Router (config-router) #log-adjacency-—changes 
clear ip ospf process 


show ip ospf neighbors Command 


This can be one of the most useful commands when verifying the operational status of OSPF. 
The show ip ospf neighbor command shows the status of all OSPF neighbors. The 
command also shows whether the neighboring router is a DR, a BDR, or a DROTHER. Fora 
neighbor to form, the Hellolnterval, RouterDeadInterval, area |Ds, and authentication type 
and password must match. Neighbors should form automatically on broadcast type networks 
such as Ethernet, Tokin Ring, and FDDI. Additional configuration is required for OSPF NMBA 
networks to help neighbors form. 


The detail argument might be appended to the show ip ospf neighbor statement to 
provide extended information on each neighbor. The detailed information includes OSPF timer 
and option information, state-change counters, and specific information on what routers are 
DR and BDR for the link. If no information is listed, when the command is performed, it 
means that no hellos have been received and accepted. If neighbors are not forming, the 
command debug ip ospf adj more than likely lists the reason why. Example 12-13 
demonstrates the command on the router john. 


Example 12-13 show ip ospf neighbor Command Output for Router 
john 
john#show ip ospf neighbors 


Neighbor ID Pra State Dead Time Address Interface 
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192,168,250. 9 a FULL/BDR 00200837 172.5:16:.9 49 Ethernet0 
1722 1642501. 1 FULL/ - 00201757 LIZ vid Ors ddegal Serial0d.1 
192168452506 1! FULL/ - 00:01252 172.16.1.6 Serial0d.1 
192.168.2503 1 FULL/ - 00:00:35 LIZ 616.5246 Serial0.2 
john# 


The fields to notice in this output are as follows: 


Neighbor | D— The neighbor ID is the router ID of the neighbor. 
Pri— This is the priority of the neighbor from this router's prospective. 


State— This field describes the neighbor state and lists whether the neighbor is a DR 


or BDR, or DROTHER. The only two normal states are 2-way and FULL. A router stuck 
in any other state indicates a problem. The state fields are defined as follows: 


- Down— This is the first OSPF neighbor state. It means that no information 
has been received from this neighbor, but hello packets still can be sent to the 
neighbor in this state. If a router doesn't receive a hello packet from a 
neighbor within the RouterDeadI nterval time (RouterDeadI nterval = 

4* Hellolnterval by default), the neighbor state changes from full to down. 


- Attempt— This state is valid only for neighbors in an NBMA environment that 
are defined by the neighbor statements. Attempt means that the router is 
sending hello packets to the neighbor but has not yet received any information. 


- Init— This state specifies that the router has received a hello packet from its 
neighbor, but the receiving router's 1D wasn't included in the hello packet. 


- 2-Way-— This state designates that bidirectional communication has been 
established between two routers. Bidirectional means that each router has 
seen the other's hello packet. At this state, a router decides whether to 
become adjacent with this neighbor. On broadcast media, a router becomes 
FULL only with the DR and the BDR; it stays in the 2-way state with all other 
neighbors. 


- Exstart— This is the first state in forming an adjacency. It is used to elect 
the master and slave routers on the link. 


- Exchange and loading— |n these states, OSPF sends link-state request 
packets and link-state update packets. 


- Full— Routers are fully adjacent with each other. All the router and network 
LSAs are exchanged, and the routers’ databases are fully synchronized. 


e Dead time— The expected time before a router receives a hello before being declared 


dead. 


e [IP] address and interface— The address is the |P address of the physical interface 
of the neighbor. The interface column states the interface in which the neighbor's hello 
was received. 


show ip ospf database Command 


The show ip ospf database command is used to show the entire OSPF database, each link 
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state in the database, and the areas they are in. Instead of referring to the link state by type, 
as in Type 1, Type 2, and so on, the database uses the alphabetic character name of the link 
state. If OSPF is aware of a network, it is in the database. The database uses router IDs to 

identify the routers advertising the link state. Example 12-14 demonstrates the command on 


the router john. 


Example 12-14 show ip ospf database Command Output on Router 
john 


john#show ip ospf database 


OSPF Router with ID (192.168.250.250) (Process ID 7) 


Router Link States (Area 0) 


Link ID ADV Router Age Seq# Checksum Link count 
LOZ. 68 «25059 19? <6 Bis250%s9 450 0x80000033 0x1370 i. 
LO2SL68«250 5250 1927 168::250..250 334 Ox8000002A OxDODA il 


Net Link States (Area 0) 


Link ID ADV Router Age Seq# Checksum 
172.416..9%.5 192.168.250.250 334 0x80000024 0xc14 


Summary Net Link States (Area 0) 


Link ID ADV Router Age Seq# Checksum 
U7 2s WOW 1.92 -168::250..250 1592 Ox8000000B 0x9242 
172 L615 192.168.250.250 1850 0x8000000B OxE729 
172.16.1..6 192.168:.250.250: 1592 Ox8000000B Ox606F 
W726 166., 254 192.168.250.250 1850 0x8000000B Ox577C 
172.653). 0 192.168.250.250 845 0x8000000B O0xC20B 
172.16 2.5 <0 192.168.250.250 1592 Ox8000000B OxD4F2 
WT Qe 6 oO) 192.168.250.250 1594 Ox8000000B 0x7356 


Router Link States (Area 10) 


Link ID ADV Router Age Seq# Checksum Link count 
172.06 .250'.2 L726 16.250). 1740 0x80000052 0x6209 3 
D926 16822. 510! 36 L921 68's250%.6 1312 0x80000025 0xK048 3 
UO2 61682250250 LI2cL68s250.250 1594 0x80000053 0x72A6 i) 


Summary Net Link States (Area 10) 


Link ID ADV Router Age Seq# Checksum 
172216624 192.168.250.250 1595 0x80000030 OxDA1 
172. 1643'.20 192.168:4250:.250: 848 0x8000000B O0xC20B 
W725 69310 192.168.250.250 92 0x8000002F OxDDO2 


Router Link States (Area 100) 


Link ID ADV Router Age Seq# Checksum Link count 
19221638: 2505.3 L992 168.2 50.53 694 0x80000051 Ox2DA0 3 
192.168.250.250 192.168.250.250 648 0x80000039 0x3291 2 


Summary Net Link States (Area 100) 
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Link ID ADV Router Age Seq# Checksum 
0.0.0.0 192.168.250.250 848 Ox8000000B 0xD202 


The fields to notice in this output are as follows: 
e ADV Router— This is the advertising router ID. 
e Age— This is the max age of the link state. 
e Seq# and Checksum— These fields are used to verify link-state integrity. 


e Tag— If an OSPF tag is added during redistribution, that will appear on a column on 
the right. 


show ip ospf interface Command 


A common problem with OSPF is incorrect network statements and wildcard masks. The best 
way to verify what the precise OSPF parameters are for an interface is to use the show ip 
opsf interface command. The important fields are the network type, the area, the process 
ID, the timers, the neighbor and the adjacency count. The DR/BDR routers and priorities also 
are listed. Example 12-15 demonstrates the command on the router mark. 


Example 12-15 show ip ospf interface Command Output for Router 
mark 


mark#show ip ospf interface 
EthernetO is up, line protocol is up 


Designated Router (ID) 172.16.5.5, Interface address 172.16.5.5 
No backup designated router on this network 


Hello due in 00:00:06 
Index 2/2, flood queue length 0 
Next 0x0 (0) /0x0(0) 
Last flood scan length is 0, maximum is 0 
Last flood scan time is 0 msec, maximum is 0 msec 


Suppress hello for 0 neighbor (s) 
Serial0O is up, line protocol is up 


Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT, 


Hello due in 00:00:05 
Index 1/1, flood queue length 0 
Next 0x0 (0) /0x0 (0) 
Last flood scan length is 1, maximum is 1 
Last flood scan time is 0 msec, maximum is O msec 
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Suppress hello for 0 neighbor (s) 
mark# 


show ip route Command 


This command shows the IP forwarding table or route table. Six types of OSPF routes can be 
listed: 


e (O)— OSPF intra-area route, or routes from the same area 
e (O1A)— OSPF inter-area route, or routes from another area 
e (ON1)— OSPF NSSA Type 1 

e (ON2)— OSPF NSSA Type 2 

e (OE1)— OSPF external Type 1 

e (O E2)— OSPF external Type 2 


For a detailed explanation of the route types, see the previous section, "OSPF Path Types." 
The route in the forwarding table is followed by the administrative distance and the cost of 
the route. The forwarding table also lists the router reporting the network, when it was 
reported, and the interface that reported it. 


show ip ospf Command 


This command provides a comprehensive view of the OSPF areas, listing the area type, 
authentication, SPF counters, redistribution, as well as detailed LSA timer information. 
Example 12-16 demonstrates this command. 


Example 12-16 show ip ospf Command Output on Router john 


john#show ip ospf 
Routing Process "“ospf 7" with ID 192.168.250.250 
Supports only single TOS(TOSO) routes 
Supports opaque LSA 
It is an area border router 
SPF schedule delay 5 secs, Hold time between two SPFs 10 secs 
Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs 
Number of external LSA 0. Checksum Sum 0x0 
Number of opaque AS LSA 0. Checksum Sum 0x0 
Number of DCbitless external and opaque AS LSA 0 
Number of DoNotAge external and opaque AS LSA 0 
Number of areas in this router is 3. 2 normal 1 stub O nssa 
External flood list length 0 
Area BACKBONE (0) 
Number of interfaces in this area is 1 
Area has no authentication 
SPF algorithm executed 11 times 
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Area ranges are 
Number of LSA 10. Checksum Sum 0x5A54A 
Number of opaque link LSA 0. Checksum Sum 0x0 
Number of DCbitless LSA 0 
Number of indication LSA 0 
Number of DoNotAge LSA 0 
Flood list length 0 
Area 10 
Number of interfaces in this area is 1 
Area has no authentication 
SPF algorithm executed 35 times 
Area ranges are 
Number of LSA 6. Checksum Sum 0x40CCF 
Number of opaque link LSA 0. Checksum Sum 0x0 
Number of DCbitless LSA 0 
Number of indication LSA 0 
Number of DoNotAge LSA 0 
Flood list length 0 
Area 100 
Number of interfaces in this area is 1 
It is a stub area, no summary LSA in this area 
generates stub default route with cost 1 
Area has no authentication 
SPF algorithm executed 32 times 
Area ranges are 
Number of LSA 3. Checksum Sum 0x10A47 
Number of opaque link LSA 0. Checksum Sum 0x0 
Number of DCbitless LSA 0 
Number of indication LSA 0 
Number of DoNotAge LSA 0 
Flood list length 0 


john# 
Gateway of last resort is not set 


172.16.0.0/16 is variably subnetted, 8 subnets, 4 masks 


O IA 172516590724 [LIC/74) vaae V/7216.1.5, 09711203, Senialo 

O LIZ. 16: VO.0729 [ADVO/13S8) via 172:-16.1.5,. 0921103, Serrald 
O 172. 16s1.5/32 [L10/64]. vad 172.06.1.5, 09511203, Serrald 

c 172.16.5.0/24 is directly connected, Ethernet0 

O IA L72516;2.4/30 [120/128] via 172.126.1265, 09211703, Séerialo 
O I72.106.1.1/32 [1107128] via 172.16.1.5,. 09:11203,. Seriald 
ic 172.16.1.0/24 is directly connected, Serial0 

O IA 172316230724: [LUC/134)] vie 172.161. 5; 08257209, Seriald 
mark# 


debug ip ospf adj and debug ip ospf events Commands 


Two debug commands provide the "Big D" for OSPF—debug ip ospf adj and debug ip ospf 
events. For the most part, the commands are identical. The output can be fairly heavy, so 
turn on logging if using this command in a production environment. This debug command is 
so comprehensive that it will alert you to a majority of common OSPF issues, such as the 
following: 


e Mismatched subnet mask 


e Mismatched hello/dead interval 
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e Mismatched authentication key 
e Mismatched area IDs and area types 


log-adjacency-changes/show log Commands 


Like EIGRP, OSPF offers a special command to log adjacency changes. This command can 
help alert you to adjacency problems without having to wade through heavy debugs. The 
syntax to log adjacency changes is as follows: 


john (config) #router ospf 7 
john (config-router) #log-adjacency-—changes 


Example 12-17 lists the log after an adjacency has been dropped. 


Example 12-17 show log Command Output Documents a Down 
Neighbor 


john#show log 
Syslog logging: enabled (0 messages dropped, 0 flushes, O overruns) 
Console logging: level debugging, 1228 messages logged 
Monitor logging: level debugging, 0 messages logged 
Buffer logging: level debugging, 2 messages logged 
Trap logging: level informational, 68 message lines logged 


Log Buffer (10000 bytes): 
1d00h: SSYS-5-CONFIG_I: Configured from console by console 
1d00h: %SOSPF-5-ADJCHG: Process 7, Nbr 172.16.250.1 on Serial0O.1 from FULL to DOW 


N, Neighbor Down 
john# 


clear ip ospf process 


Available as of Cisco |OS Software Release 12.0, this command clears all OSPF neighbors, the 
RID, and the SPF database. This command initializes the entire OSPF process as if the router 
were reloaded. 
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Configuring OSPF Stub Areas 


Three types of OSPF stub areas must be configured: 


e Stub 
e NSSA 
e Totally stubby 


To configure stub areas, use the area command followed by what type of stub area you want 
to configure. All routers on the same IP network must be in the same area, and area 
parameters also must match for neighbors and adjacencies to form. 


To configure Area X as a stub area, enter the following: 
Router (config-route) area X stub 
To configure Area X as a not-so-stubby area, enter the following: 


Router (config-route)area X nssa {default-information originate}. 


Use the keyword default-information originate on the area statement in the preceding 
example to propagate a default route to an NSSA area. 


To configure Area X as a totally stubby area, enter the following: 


Router (config-route) area X stub no-summary 


772 


Tuning OSPF 


OSPF has several parameters for tuning timers, controlling broadcasts, and controlling routes 
and link-state propagation. The following list shows the syntax of the more common 
parameters adjustable for OSPF, explained in the text that follows. 


Router (config-if)ip ospf hello-interval interval_in_seconds 
Router (config-if)ip ospf dead-interval dead_interval_in_seconds 
Router (config-if)ip ospf retransmit-interval 


Use the ip ospf hello-interval interface command to change the hello timer for OSPF. The 
default value of this command is interface-dependent. By default, hello packets are sent 
every 10 seconds on broadcast and point-to-point networks, and 30 seconds on NBMA 
networks. All neighbors residing on a network and area should have equal hello timers. The 
dead-interval and wait timer automatically are changed when the hello interval is changed. 


Use the ip ospf dead-interval command to change the dead interval received by this 
interface. The timer has a default vault of four times that of the hello timer, 40 seconds for 
broadcast and point-to-point networks, and 120 seconds for NBMA networks. Recall that the 
dead interval is the time that has to pass before a neighbor receives a hello before declaring 
it "dead." 


Use the ip ospf retransmit-interval command to change OSPF retransmission interval. All 
routers in the area should have the time set to the same value. 
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OSPF Flooding Reduction 


OSPF flooding reduction was introduced in Cisco |OS Software Release 12.1(2)T. Inherently, 
OSPF LSAs are refreshed every 3600 seconds. In large, fairly stable OSPF networks, this can 
lead to large amounts of unnecessary LSA flooding from area to area. Technically, if an LSA 
has not changed, why reflood it every 3600 seconds? OSPF flooding control is a new 
technique that changes normal LSAs into DoNotAge LSAs. Therefore, they will not get flooded 
every 3600 seconds across areas. For this feature to work, all routers in the area that are 
connected to the router performing flooding control must be running Cisco 1OS Software 
Release 12.1(2)T or later. To enable flooding control on the interface, use the following 
interface command: 


Router (config-if) #ip ospf flood-reduction 


Additionally, you can choose to block all LSA flooding out an interface. To block OSPF flooding 
of LSAs on broadcast, nonbroadcast, and point-to-point interfaces, use this following 
interface command: 


Router (config-if) #ospf database-filter all out 


To block LSAs flooding to a specific neighbor, use the following router command on the 
neighbor statement: 


Router (config-router) #neighbor ip_address database-filter all out 
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OSPF Redistribution and Route Control 


To filter specific routing updates in OSPF, you must use an inbound distribution list. An OSPF router does 
not send routing updates in the traditional manner; therefore, only an inbound distribution list on the 
router receiving the update works for route control. When redistributing one protocol into another, use 
the redistribute command along with the default metric. A route map should be used in place of a 
distribute list when controlling specific routes during the redistribution process. A route map provides for 
many more options during redistribution and is a powerful routing tool. 


Commands to Control Route Filtering/Redistribution 


To call a standard access list to filter inbound routing updates, use the following command: 


Router (config-router) distribute-list [1-99] [in] [interface_name] 


The in option is applied from the view of the interface. In other words, to prevent a routing update from 
entering an interface, use the in option. This command filters only the route, not the LSA. 


To redistribute other routing protocols into OSPF, use the following command: 


Router (config-router) redistribute [connected | static | bgp | rip | igrp | eigrp | 
isis] [subnets] [tag tag_number] [metric cost] [metric-type {OE1 | OE2 } ] 
[route-map] 


With OSPF, the keyword subnets always should be used when redistributing more then one network into 
OSPF. When redistributing routes into OSPF, only routes that are not subnetted are redistributed if the 
subnets keyword is not specified. An optional tag can be added during redistribution. This tag appears in 
the OSPF database and can be used to quickly identify where route redistribution occurs in the 
internetwork. A route map might be added for additional route control. An optional metric/cost also can 
be supplied for routes originating from the routing protocol being redistributed that are different from the 
default metric. When OSPF redistributes routes, the default route type will be an OSPF external Type 2 
route (O E2). To change this to an OSPF external Type 1 route (O E1), use the metric-type argument 
on the redistribution command. 


To set the default cost of all routes redistributed into OSPF, use the following command: 


Router (config-router) default-metric [cost 1-4294967295] 


You must supply a default metric whenever redistributing. A common metric to use is default-metric 
10. Recall from the previous chapter that more important than the actual value of the default metric is 
the practice of using the same metric throughout the routing domain, so all redistributed routes will have 
the same cost. 


Commands to Influence OSPF Routing Decisions 


You can control routing updates within OSPF in multiple ways. Recall that OSPF calculates a cost toa 
destination based on a formula involving bandwidth. To influence route decisions, you can either change 
the bandwidth on the interface, which in turn will affect the cost of the link, or directly change the cost of 
the interface. 


OSPF also supports the direct changing of the administrative distance with the distance command, much 
like EIGRP. OSPF also uses the passive interface command to prevent hellos from being sent on the link. 


To specify the cost of an interface in OSPF, use the following command: 
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Router (config-if)cost_[cost 1-4294967295] 


This command is used only by OSPF and does not affect the actual traffic on the link. 
To specify the bandwidth of an interface in kilobits per second, use the following command: 


Router (config-if)bandwidth [bandwidth_kbps 1-4214748364] 


The bandwidth command is used only by routing protocols to derive a cost for the interface, and it also 
does not affect the actual traffic on the link. 


To change the administrative distance of OSPF routes, use the following command: 


Router (config-router) distance ospf {[intra-area [1-255] [inter-area [1-255] 
[external [1-255] } 


OSPF uses three different administrative distances: intra-area, interarea, and external. Routes within an 
area are intra-area; routes from another area are interarea; and routes injected by redistribution are 
external. The default administrative distance for each type of route is 110. 


To prevent the sending of OSPF hellos on the link, use the following command: 


Router (config-router) passive-interface interface_name 


Because hellos are suppressed, neighbors will not be formed, so no routing updates will be sent or 
received. 


Practical Example: Route Filtering/Redistribution 


Let's apply a couple of these concepts to a practical model in route filtering and redistribution to gain a 
better grasp of them. Figure 12-9 modifies the internetwork from the previous model in Example 12-8. 


The mark router is now an ASBR between the OSPF domain and a RIP domain. You also will redistribute 
some loopback interfaces on the router paul. On the mathew router, you will apply an inbound 
distribution list to filter the external networks or the loopback networks from the router paul. 


Figure 12-9. OSPF Network for Route Filtering/ Redistribution 
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Beginning with the paul router, we have added two loopback interfaces, 128.100.1.1/24 and 
128.100.2.1/24. To redistribute these networks, you will use the redistribute connected command 
with the subnets argument. The default metric or cost will be set to 10. In this example, a tag is set on 
the redistribution. Example 12-20 illustrates how the tag shows up in the OSPF database. Example 12-18 


lists the relevant configuration of the router paul. 


Example 12-18 Configuration of the paul Router 


interface Loopback20 

ip address 128.100.1.1 255.255.255.0 
no ip directed-broadcast 

! 

interface Loopback21 

ip address 128.100.2.1 255.255.255.0 


no ip directed-broadcast 
! 


interface Ethernet0/0 

ip address 172.16.9.9 255.255.255.0 
no ip directed-broadcast 

! 
<<<text omitted>>> 

! 

router ospf 7 

router-id 192.168.250.9 


~ redistribute the loopback interfaces 
network 172.16.9.0 0.0.0.255 area 0 


default-metric 10 = Use a cost of 10 on redistributed networks 


To verify the redistribution, perform show ip route on the mark router. Example 12-19 demonstrates 
this command. 
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Example 12-19 show ip route on Router mark 


mark#show ip route 
Codes: C = connected, S - static, I - IGRP, R —- RIP, M — mobile, B = BGP 
D -— EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El = OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i= IS=18,; Li = IS=-1S leével=1, L2.= IS=1S. level=2, ia = IS=1S. inter area 
* — candidate default, U - per-user static route, o —- ODR 
P — periodic downloaded static route 


Gateway of last resort is not set 


172.16.0.0/16 is variably subnetted, 8 subnets, 4 masks 


O IA LI2Z.16. 90/24 [110/74] wie LI2 16.1.5, 08258: 07). Serival0 

fe) 172.16.10.0/724 [110/138] vie 172.16.1.5, 18s33:11, Séeriald 

O L72.16.1.5/32 [110/64] vie 2172.16.15, 18333311, Seriald 

c 172.16.5.0/24 is directly connected, Ethernet0O 

O IA 172.316.2.4/30 [110/128] via 172.16.1.5, 08:58:08, Serialo 

O VIZcV6<I 21/32 [1107128] wie IIe. 6.1 5, L8s3s3t11,. Serial 0 

Cc 172.16.1.0/24 is directly connected, Serial0 

O IA 172 ~16.3.0/24: (110/134) whe 172.160.1165, 08258509, Serial0 
128.100.0.0/24 is subnetted, 2 subnets 


~ redistributed routes 


O E2 128.100.2<.0° [110/20] wie 172.162.1245, 0G:50509, Serialo 


During redistribution, we also put a tag of 9 on the routes. Example 12-20 lists the OSPF database of 
mark showing how the tag is propagated throughout OSPF. 


Example 12-20 OSPF Database on the Router mark 


mark#show ip ospf database 
OSPF Router with ID (192.168.250.6) (Process ID 7) 
<<text omitted>>> 
Type-5 AS External Link States 


Link ID ADV Router Age Seq# Checksum Tag 
L723 16..9.0 192°168:250..9 844 0x80000026 0x3807 
mark# 


Notice that during redistribution, the 172.16.9.0 route also is redistributed. This is because the Ethernet 
network also is considered a local network. To prevent this from happening, add a route map to the 
redistribution command to filter any unwanted networks. 


Next, you will integrate the RIP domain into OSPF on the router mark. To accomplish this, enable RIP on 
the mark router. When doing this, you will put the EO interface into a passive state for OSPF and the SO 
interface into a passive state for RIP. A more specific network command also will accomplish this, which 
is another good reason to limit the wildcard mask on the network command to a single network or 
interface. To enable redistribution, use the redistribute rip subnets command on the mark router. 
Likewise, you will have to redistribute OSPF into RIP. The default metric that you will use for OSPF is 10. 
Example 12-21 shows the OSPF portion of router mark. 


Example 12-21 Routing Protocol Configuration of mark 778 


router ospf 7 
router-id 192.168.250.6 


redistribute rip subnets” redistribute RIP into OSPF 
~~? No OSPF hellos out BO (optional) 
network 172.16.1.0 0.0.0.255 area 10 
default-metric 10 ©? Use 10 as the cost to the RIP domain 
! 
router rip 
redistribute ospf 7 ==)’ redistribute OSPF into RIP 
~~ No RIP broadcasts out 80 
network 172.16.0.0 


default-metric 3 =” Use a hop count of 3 for OSPF routes 


Because one redistribution point exists in the network, you do not have to worry about redistribution 
loops or "route feedback." Before redistribution will be complete, you have to summarize the 
172.16.2.4/30 network. This is because RIP receives routes through an interface on a 24-bit boundary. 
In this model, you accomplished this with the area range command. We will discuss more about this in 
the next session. The best way to verify redistribution in this model is to view the route table of the 
router peter and verify that all the OSPF routes are reachable by ping tests. Example 12-22 lists the 


route table of peter. 


Example 12-22 Route Table of peter After Redistribution 


peter#show ip route 
<<<text omitted>>> 


Gateway of last resort is not set 


172.16.0.0/16 is variably subnetted, 8 subnets, 2 masks 
R 172.16.9.0/24 [120/3] via 172.16.5.5, 00:00:01, Ethernet0 
R 172.16.10.0/24 [120/3] via 172.16.5.5, 00:00:01, Ethernet0O 
R 172.16.1.5/32 [120/3] via 172.16.5.5, 00:00:01, Ethernet0 
c 172.16.5.0/24 is directly connected, Ethernet0 
R 172.1651.1/32 [120/3] via 172.16:5.5, 00:00:02, Ethernet 0 
R 172.1651.0/24 [120/11] via 172.16:.5.5, 00:00:02, Etherneto 
R 172.16.2.0/24 [120/3] via 172.16.5.5, 00:00:02, Ethernet0 
R 172.16.3.0/24 [120/3] via 172.16.5.5, 00:00:02, Ethernet0O 
R 128.100.0.0/16. [120/3] via 172.16.5.5, 00:00:02, Ethernet0O 
peter# 


To demonstrate route filtering in OSPF, you will apply an inbound distribute list to the router mathew. 
The configuration of the mathew router resembles the following example. At the end of Example 12-23 is 


the new route table for mathew, without the 128.100.1.0/24 and 128.100.2.0/24 routes. 


Example 12-23 Distribute List on the mathew Router 


router ospf 7 
network 172.16.1.0 0.0.0.255 area 10 
network 172.16.10.0 0.0.0.255 area 10 


(distribute-list 10 in Serialo = “distribute list applied to s0 
! 


ip classless 
! 


access-list 10 permit any 
! 


mathew#show ip route 
Codes: C -— connected, S -— static, I - IGRP, R - RIP, M -— mobile, B - BGP 
D — EIGRP, EX — EIGRP external, O — OSPF, IA —- OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i = 28=1S, Li. = TS=1S léevel=1,; 12 = TS=1I8. level=2,; * = candidate default 
U - per-user static route, o — ODR 


Gateway of last resort is not set 


172.16.0.0/16 is variably subnetted, 9 subnets, 2 masks 


Cc 172.16.250.0/24 is directly connected, Loopback0O 

O IA 1724162.9.0/24. (110/74) via 172.16.1.5, 01201206; Seriald 
Cc 172.16.10.0/24 is directly connected, Ethernet2 

O L72<L6.1.5/32 [VLOs64)] vie LI2.16.1.5, O1201206,. Seriado 
fe) 172.16.5.0/24 [110/129] via 172.16.1.5, 01:01:06, Serial0 
0) 172216.1.6/32 [110/128] via 172.16.1.5, O1501206, Serial0o 
ic 172.16.1.0/24 is directly connected, Serial0 

oO IA LI2<16.2.0/ 24. (110/128). vid 172.16.1.5, 01201206, Serial o 
O IA LIZ.16.3 0/24 [T10/134) wha TI2516,1.5, O12012 06, Seriralo 
mathew# 
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OSPF Summarization 


OSPF allows for two forms of summarization. One form of summarization is used when 
summarizing routes redistributed into OSPF from another routing protocol. The other form of 
summarization is used when summarizing an area. With both forms of summarization, summary 
LSAs are created and flooded toward Area 0, or the backbone area. The backbone area, in turn, 
floods the link states to the other areas. Use these guidelines when configuring summarization 
in OSPF: 


e Use continuous address space in each OSPF area. This allows for easy summarization on 
the ABRs. Summarizing many networks into a single advertisement decreases the route 
table and improves the overall performance and scalability of OSPF. 

e Summarize on major bit boundaries or simple octet boundaries whenever possible. If 
you have a classful routing protocol in your network, such as RIP or IGRP, you must 
summarize on bit boundaries that the classful routing protocol can receive. 

e You cannot summarize Area O or the backbone area. All summaries are flooded into Area 
0 and then are flooded out from that point. Therefore, Area 0 routes cannot be 
summarized. 


To summarize external routes, or routes redistributed into OSPF, use the following router 
command on the ASBR: 


Router (config-router) summary-address network_address network_mask [tag tag_number] 


The tag parameter can be used in the same manner as it is during redistribution, to mark 
routes with a numeric number. 


To summarize routes from one OSPF area into Area 0, use the following router command: 


Router (config-router) area area_id range network_address network_mask 


In Figure 12-10, we have modified the network once again. We have changed some interfaces 
and increased the networks in the RIP domain. OSPF Area 20 now contains the subnets 
100.10.1.0/24 to 100.10.3.0/24. First, you will want to summarize these networks into a single 
route, 100.10.0.0/16. To accomplish this, you will use the router command area 20 range 
100.10.0.0 255.255.0.0 on the ABR, or the router john. The router john will advertise the 
summary route 100.10.0.0/16 to mark. This is referred to as interarea summarization. 


Figure 12-10. Summarizing OSPF 
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This network must use another form of interarea summarization for full |P connectivity to the 
RIP domain. The RIP Ethernet interface has an IP address on a 24-bit boundary. Recall from 
Chapter 9, "Distance Vector Protocols: Routing Information Protocol Versions 1 and 2 (RIP-1 
and RIP-2)," that for RIP to receive a route, it must be on a natural bit boundary 8, 16, or 24, 
or on the same bit boundary that the interface receiving the route is on—in this case, a 24-bit 
boundary. This is true for |GRP as well. All of the networks in the OSPF domain reside on a 24- 
bit boundary except for the Frame Relay point-to-point network between the routers john and 
luke. To accommodate RIP, you must summarize the Frame Relay point-to-point network at a 
24-bit boundary. To summarize the 172.16.2.4/30 network into 172.16.2.0/24, use the area 
100 range 172.16.2.0 255.255.255.0 command on the router john. The router john will now 
advertise the summary route 172.16.2.0/24 to mark and finally to peter. Example 12-24 lists 
the route table on the mark router. 


Example 12-24 Route Table of the mark Router 


mark#show ip route 
Codes: C - connected, S —- static, I - IGRP, R — RIP, M — mobile, B — BGP 
D — EIGRP, EX — EIGRP external, O — OSPF, IA —- OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area 
* — candidate default, U - per-user static route, o — ODR 
P -— periodic downloaded static route 
Gateway of last resort is not set 
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100.0.0.0/16 is subnetted, 1 subnets 


O IA 100.10.0.0 [210/129] waa 172.16.6.5, 00:°26:45, Serial0.1 
172.16.0.0/24 is subnetted, 6 subnets 

O IA 172.16.9.0 [110/74] via 172.16.6.5, 00:26:45, Serial0.1 

Cc 172.16.6.0 is directly connected, Serial0O.1 

O IA 17216.1..0 [110/128] vie 1772.16.65, 00:26:45, Serial0.1 

O IA 172.16.2.0 [110/128] via 172.16.6.5, 00326:45, Serial0.1 

O IA 1172.16.30 [110/134] via 172.16.6.5,. 00:26:45, Serial0.1 

Cc 172.16.100.0 is directly connected, Ethernet0O 
128.100.0.0/24 is subnetted, 2 subnets 

O E2 128.100.2120 110/20) Waa 172.16.6.5,. 00326245, Séeriald <1 

O E2 128..100.2..0° [110/20] vWia.172.16.6.5; 00:26:45, Seri1al0d.1 

R 192.168.1.0/24 [120/1] via 172.16.100.8, 00:00:06, Ethernet0O 

R 192.168.2.0/24 [120/1] via 172.16.100.8, 00:00:07, Ethernet0O 


mark# 


The final summary that you want to perform is external summarization. On the mark router, 
you want to summarize the two RIP routes 192.168.1.0/24 and 192.168.2.0/24 into a single 
OSPF route 192.168.0.0/16. To perform this task, use the OSPF router command summary- 
address 192.168.0.0 255.255.0.0. Example 12-25 lists the routing protocol configurations of 


the john and mark routers, respectively. 


Example 12-25 john and mark Configurations 


hostname mark 

! 

router ospf 7 

router-id 192.168.250.6 
summary-—address 192.168.0.0 255.255.255.0 
redistribute rip subnets 
passive-interface Ethernet0O 

network 172.16.6.0 0.0.0.255 area 10 
default-metric 10 

! 

router rip 

redistribute ospf 7 
passive-interface Serial0 

network 172.16.0.0 


default-metric 3 
! 


hostname john 
! 
router ospf 7 
router-id 192.168.250.250 
area 7 stub 
area 20 range 100.10.0.0 255.255.0.0 
area 100 stub no-summary 
area 100 range 172.16.2.0 255.255.255.0 


network 172.16.1.0 0.0.0.255 area 20 
network 172.16.2.4 0.0.0.3 area 100 
network 172.16.6.0 0.0.0.255 area 10 
network 172.16.9.0 0.0.0.255 area 0 


Example 12-26 lists the route table of paul, listing all the summary routes. 
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Example 12-26 Route Table of paul 


paul#show ip route 
<<<text omitted>>> 


Gateway of last resort is not set 


O IA 
c 
O IA 
O IA 
O IA 
O IA 
O E2 
Cc 
Cc 


100.0.0.0/16 is subnetted, 1 subnets 


WZ 


128. 


100.10..07,.0 
16.0.0/24 
112 16690 
12.164 '6.5 0 
L726 1601.0 
LI2616.2..0 
E25 6.35.0 
L216. L009 
100.0.0/24 
128: 100.120 
125:.100.2.0 


O E2 192.168.0.0/16 


paul# 


[110/74] via 172.16.9. 
[110/80] via 172.16.9. 
20 [110/107 


Vile L226, 


is subnetted, 2 subnets 
is directly connected, Loopback20 
is directly connected, Loopback21 


[110/10] 


Vid 172.16.9...5, 


, kdZ22h, 


Oars Os Ay 


QOFOL2 17, 


[L10/75] waa 172.16.9.5, 1d22n; Bthernet0/0 

is subnetted, 6 subnets 

is directly connected, Ethernet0/0 

[110/74] via 172.16.9.5 Ethernet0/0 

[110/74] vila 172.16.9.5, Td22h; Btherneto/0 
5, 1d22h, Ethernet0/0 
5 


, 1d22h, Ethernet0/0 


Ethernet0/0 


Ethernet0/0 
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OSPF Default Routing 


Today, most, and potentially all, networks connect to the Internet. Some routers have 
registered address space, while others have Internet routers, or firewalls. Being able to 
generate and propagate a default route is important. Recall from earlier chapters that default 
routing is a three-step task: 


Step 1. Mark or "flag" a network as a default. A route must be "flagged" a default 
route before OSPF will treat it as a default route. This can be done in one of two ways 
with the following global commands: 


Router (config)ip default-network network_address 


Router (config)ip route 0.0.0.0 0.0.0.0 ip_address 


This particular static route does not need to be redistributed into OSPF to be 
propagated. OSPF will recognize the 0.0.0.0 0.0.0.0 route as a default and treat it 
accordingly. If you use the default-network statement, you need to use the keyword 
always in Step 2. 


Step 2. Propagate the default network. Use the following OSPF router command: 


default-information originate [always] [metric cost] [metric-type OE1 | 
OE2] [route-map map-name] 


Step 3. Enable IP classless. Recall from previous chapters, that for any routing 
protocol to forward packets to a destination that does not appear in the route table, 
the router needs ip classless enabled. By default, ip classless in enabled in Cisco 
10S Software Release 12.0 and later. 


Figure 12-11 adds another connection, 206.191.200.1, to the network that is the gateway to 


the Internet. To flag the network 206.191.200.0 as a default network, either of the two 
global configuration commands will work: 


Figure 12-11. OSPF Default Routing 
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* IP IPs 172.16, 1,524 
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i Ed 
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' OSPF ° 
Flb= 12. 1h 
! mark — a1 Area 100 | 
' Rite 82, 168 245.5 San, : Totally | 
, OSPF $0.1 polnt-io-poant Stubby | 
' Area 10 30.1 podnt-to-pairat 
“Dee ------- IPSIT2 Bed I 
I 
r 


z= 


ee ee eee ee eee 


$0.1 point-to-point ~ 
[Pat 7216.1. 184 


Filet, 166.250.1 
2 (P= 1000.10.39. 124 


eee eee eee 


ip default-network 206.191.200.0 


Or point it directly at an address: 


ip route 0.0.0.0 0.0.0.0 206.191.200.1 


To propagate the default network, use the default-information originate always 
command. The always keyword always propagates a default route if the router flags the 
default network with the default-network command. 


Example 12-27 lists the configuration of paul and shows how the default route is configured. 


Example 12-27 Default Route Configuration on paul 


router ospf 7 

router-id 192.168.250.9 

redistribute connected subnets tag 9 

network 172.16.9.0 0.0.0.255 area 0 
_default-information originate always = = *~ Propagate the default route 
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PsI7216.2.800 ._ Too 
xy Paeneson 
1.544 Mbps _- 


default-metric 10 
' 


ip classiess == "I classless is always needed 
ip route 0.0.0.0 0.0.0.0 206.191.200.1  *~ "Flag" the route as default 
! 


Example 12-28 lists how the route is propagated into the NSSA area on the router mathew. 
Notice that the gateway of last resort now is set. 


Example 12-28 Route Table of mathew 


mathew#show ip route 
<<<text omitted>>> 


100.0.0.0/24 is subnetted, 3 subnets 
100.10.2.0 is directly connected, Loopback21 
100.10.3.0 is directly connected, Ethernet2 
100.10.1.0 is directly connected, Loopback20 
172.16.0.0/24 is subnetted, 8 subnets 
172.16.250.0 is directly connected, LoopbackO 
IA 172.16.9.0 [110/74] via 172.16.1.5, Ld23h, Seriald.1 
172.16.10.0 is a summary, 2d00h, Null10 
IA LIZ sl6c6<0 [110/126] waa L72.16.1.5,; 2d23h,. Serialo.1 
172.16.1.0 is directly connected, Serial0O.1 
172.16.2.0 is a summary, 2d00h, Null0 
IA 172.16.3;0 [110/134] vie L72.16.1.5;, 1d23h; Seriald.1 
E2 172.16.100.0 [110/10] via 172.16.1.5, 02:54:58, Serial0.1 
B2 206:;191.200.0/24 [110/20] vie 172.16.1,5, 00309256, Seriald.i 
12.0.0.0/16 is subnetted, 1 subnets 
12 ,.16.0.0:. [110/10] vie: 172.516.1535; Ld23h, Serialo. i 


aaa 


oO OO © ©) OO OO 


oS 
ical 
i) 


O B2 192..168.0.0/16 [110/710] via 272.106.1145, 01236:57, Serial0.1 
mathew# 


787 


OSPF Authentication 


OSPF uses two forms of authentication, Type | and Type II. Both forms are fairly easy and 
straightforward to configure. When configuring passwords, do not enter an encryption type for the 
password on the interface. Instead, use the global command service password-encryption to 
enable all password protection after all the configuration is complete. 


Type 1 Authentication 


Type 1 authentication is clear-text authentication. If a sniffer is placed on a network, the password 
still can be captured, so this is less secure than Type 2. To configure Type 1 authentication, follow 
this two-step process: 


Step 1. Enable area authentication on all routers in that area. Use this router command: 
Router (config-route)area area_id authentication 

Step 2. Enter the clear-text password on the interface. Use this interface command: 
Router (config-if) ip ospf authentication-key password. 


The passwords and authentication must match for all interfaces in that area, or adjacencies 
will not be formed. 


Type 2 Authentication 


Type 2 authentication is Message Digest 5 (MD5) cryptographic checksums. OSPF builds a hash 
value from the OSPF key and password. The hash is the only value sent across the link; no 
passwords are sent, making MD5 authentication secure. To configure Type 2 (MD5), authentication, 
follow this two-step process: 


Step 1. Enable MD5 area authentication on all routers in that area. Use this router command: 
Router (config-route)area area_id authentication message-digest 

Step 2. Set a key and password on a per-interface basis. Use this interface command: 
Router (config-if) ip ospf message-digest-key key_value md5 password 


The key_value and password must match on all routers in that network. Different key values 
allow for quick changes of passwords and multiple passwords per area. 


Type 1/Type 2 Authentication Example 


Figure 12-12 shows a portion of a network in Area 10. Example 12-29 and Example 12-30 show 
Type 1 and Type 2 authentication options for OSPF in this network. 


Figure 12-12. OSPF Authentication 
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Example 12-29 Example 12-29 OSPF Type 1 Authentication on Area 10 


! 
hostname peter 
! 
interface Ethernet0O 
ip address 172.16.100.8 255.255.255.0 


ip ospf authentication-key cisco” Cisco is the password 
! 


router ospf 7 
network 172.16.100.8 0.0.0.0 area 10 


hostname mark 
! 
interface Ethernet0O 
ip address 172.16.100.6 255.255.255.0 
no ip directed-broadcast 
ip ospf authentication-key cisco 
! 
router ospf 7 
router-id 192.168.250.6 


network 172.16.6.0 0.0. 
6 0. 


network 172.16.100. 
! 


255 area 10 
0 


0. 
0.0.0 area 10 


Example 12-30 is the same configuration for Figure 12-11 using MD5 authentication. 


Example 12-30 OSPF Type 2 Authentication on Area 10 


hostname peter 
! 
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interface Ethernet0O 
ip address 172.16.100.8 255.255.255.0 


ip ospf message-digest-key 1 md5 cisco —* Cisco is the password, key=1 
! 


router ospf 7 
network 172.16.100.8 0.0.0.0 area 10 


ee eee eee =— eee 
hostname mark 

! 
interface Ethernet0O 


ip address 172.16.100.6 255.255.255.0 
no ip directed-broadcast 


! 
router ospf 7 
router-id 192.168.250.6 


network 172.16.6.0 


network 172.16.100 
! 


255 area 10 


0.0.0. 
-6 0.0.0.0 area 10 
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OSPF Demand Circuits and Backup 


Backup with OSPF can be difficult, especially with dial-on-demand backup such as ISDN. 
OSPF becomes difficult in the backup mode because of area connectivity. The key to how you 
control backup interfaces depends on what OSPF area the backup interface is in. Because of 
the different area properties, such as what LSA get flooded to what areas, the area selection 
for backup is important. Where the router is located in the network, the area type, and how it 
connects to Area O will also influence what area the backup interface goes in. Instead of 
going over the countless possible examples for demand circuits and OSPF backup, we instead 
cover configuration guidelines and issues. For specific lab examples and more information on 
the backup interface and OSPF demand circuits, see Chapter 7, "WAN Protocols and 
Technologies: Integrated Services Digital Network (ISDN)." The sections that follow cover the 
configuration guidelines for OSPF demand circuits and backup. 


Adhere to OSPF Design Rules 


When the backup link becomes active, the network still must comply with all OSPF design 
guidelines. That is, Area 0 cannot be partitioned, virtual links cannot be run through stub 
areas, all areas must connect to Area 0, and so on. The network topology will change when in 
backup mode, but it still must adhere to the same OSPF guidelines. 


OSPF Demand Circuits 


RFC 1793 outlines the original standard for OSPF demand circuits. Essentially, OSPF demand 
circuits will spoof hellos, 224.0.0.5, from activating dial-on-demand circuits. It attempts to 
control LSA flooding by exchanging LSA information only the first time that the circuit is 
activated and by setting the LSA DoNotAge bit. If the dial link is in Area 0, or if the OSPF 
internetwork has external LSAs or LSA Type 5s or is in an NSSA area with LSA Type 7s, a 
demand circuit will not operate properly. Type 5 and Type 7 LSAs or NSSA LSAs force a DDR 
link, such as ISDN, to constantly dial. Most networks have some form of redistribution and 
almost always have LSA Type 5s floating around. Only a stub area used in conjunction with 
demand circuit will prevent the DDR link from constant dialing because of LSA Type 5s. To 
configure a demand circuit, use the following three-step process: 


Step 1. Configure the interfaces on both sides of the network as OSPF point-to-point 
networks. Remember that hellos cannot be suppressed on "broadcast" networks, and 
virtual links cannot be run through stub areas. 


Step 2. Configure the interfaces to be in the same stub area. Use the router 
command Area x stub. 


Step 3. Configure only one side, the "dialing" side of network, to be the demand 
circuit. Use the interface command ip ospf demand-circuit. 


Area 0 Guidelines 


The backup interface should go into Area 0 only if the primary interface is in Area 0. If 
dynamic routing is to occur, use the backup interface command or dialer watch 
commands. Remember, all LSAs will be flooded into Area 0. This type of constant LSA 
flooding to Area O will cause constant dialing of the interface. In cases such as this, the 
interface must be forced not to dial with additional configuration techniques. 
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OSPF Virtual Links 


We discuss OSPF virtual links last because they should be used as your last option. The Cisco 
design guide warns that the use of virtual links is an indication of poor design, and, for the 
most part, this is correct. Virtual links are used to extend Area O across another area. They 
also can be thought of as tunnels for LSAs. They are deployed in cases when areas become 
partitioned or an area does not border Area 0. To configure a virtual link, use the following 
router command: 


Router (config-route) #area transit_area_id virtual-link router_id_of_remote 


The area_id is the "transit area" that OSPF will tunnel through. The "transit area" cannot be a 
stub area of any kind. At the end of the tunnel will be another router terminating the virtual 
link; use the router ID of that router in the router_id field. Virtual links use RIDs, and they 
are another reason why we use fixed RIDs when configuring OSPF. It is important that any 
timer changes or OSPF authentication applied to Area 0 also must be applied to the other 
side of the virtual link. Remember that a virtual link is actually an extension of Area 0. Think 
of the virtual link as the router's new interface into Area 0. Configure all interface options on 
the virtual link. 


In Figure 12-13, the router peter is in Area 200. Notice that Area 200 does not directly touch 
Area 0. To make this network functional, you need to define a virtual link across Area 10. On 
the router mark, define a virtual link using Area 10 as the transit area, terminating it at the 

router ID of 192.168.250.250 or the router john. On the router john, configure a virtual link 
by using Area 10 as the transit area, and terminate the link at router 1D 192.168.250.6. The 
precise syntax for each virtual link is highlighted in Figure 12-13. 


Figure 12-13. OSPF Virtual Links 
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To verify the functionality of a virtual link, use the command show ip ospf virtual-links 
along with standard show ip route and ping tests. The virtual link should be up and the 
adjacency state should be FULL when it is operating properly. If the link does not come up, 
ensure that the router IDs are the ones that OSPF is using. View the OSPF database if you 
are unsure what the current router 1D is. Example 12-31 lists the output of the show ip ospf 


virtual-links command performed on the router john. 


Example 12-31 Verifying a Virtual Link 


john#show ip ospf virtual-links 


Run as demand circuit 

DONotAge LSA allowed. 

Transit area 10, via interface Serial0.1, Cost of using 64 

Transmit Delay is 1 sec, State POINT_TO_POINT, 

Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 
Hello due in 00:00:09 
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Index 2/5, retransmission queue length 0, number of retransmission 1 
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0) 
Last retransmission scan length is 1, maximum is 1 
Last retransmission scan time is 0 msec, maximum is O msec 
john# 
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Lab 24: OSPF Multiple Area Routing, Authentication, Path 
Manipulation, Default Routing—Part | 


Practical Scenario 


Throughout this text, we have stated that most networks today are connected to the Internet in 
some form. Connecting to the Internet usually requires a default route to be propagated 
throughout the network. The following lab gives you practice in configuring multiple OSPF areas 
and types, authenticating an area, manipulating paths, and propagating a default route 
throughout OSPF. 


Lab Exercise 


The famous Dr. Stai has a small group of regional offices. Each office specializes in a specific area 
of dentistry, such as root canals or fillings. Dr. Stai wants to connect the offices over a Frame 
Relay network. The offices also will share a common connection to the Internet so that they can 
have access to the latest techniques and new pain-reduction methods. Your task is to configure 
an OSPF network by using the following parameters as design guidelines: 


e Configure an |1P network, as depicted in Figure 12-14, by using OSPF as the routing 
protocol and 2002 as the Autonomous System ID. 


Figure 12-14. Dr. Stai's Dental Network 
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Configure the Frame Relay network as a point-to-point network between dental_ho and 
the router fillings. Use a Frame Relay multipoint network between the dental_ ho, crowns, 
and root_canals routers. 

Configure all the OSPF areas as denoted in the diagram. Area 10 is to be configured as a 
NSSA area. 

Inject a default route into the dental_ho router pointing all Internet traffic toward the 
network 128.10.1.0/24. Propagate the default route within the OSPF domain. 

Configure Type 2 authentication in Area 200. 

The root_canals router has a T1 to the dental_ho router. Configure the network so that the 
pain_center router will use the T1 of root_canals over the crowns router's 64-kbps link 
when accessing any networks across the WAN. 


Lab Objectives 


Configure Dr. Stai's dental network as depicted in Figure 12-14. Configure IP as denoted in 


the figure, as well. The LAN topology type is not important in this lab. 

Use the Frame Relay data link protocol on the WAN. Use only multipoint networks and 
point-to-point networks, as indicated in the figure. 

Ensure full 1P connectivity to all IP interfaces—that is, be sure that you can ping all Frame 
Relay and LAN interfaces. 

Do not change the default OSPF network type. Do not use any static routes. 

Inject a default route into the dental_ho router. Direct all |P traffic toward the subnet 
128.10.1.0/24. Use a default network to accomplish this. Propagate the default route 
within OSPF. 


Use Type 2 authentication on Area 200. Use cisco as the password. aa 


e Tune OSPF so that the pain_center router will have a preferred path through the router 
root_canals router over the crowns router. That is, all traffic from the pain_ center router 
should travel through the router root_canals. 

e (Optional) Propagate the default route only if the subnet 128.10.1.0/24 is present in the 
route table of the dental_ho router. If this route is not present, the default route should 
not get propagated because the dental_ho router cannot reach it. Note: You will be able to 
control only the default route to normal areas in this lab, so do not worry about controlling 
it in the NSSA area. 


Equipment Needed 


e Six Cisco routers. Four will be connected through V.35 back-to-back cables or in a similar 
manner to a Frame Relay switch. 

e Three LAN segments, provided by hubs or switches. The LAN topology is not significant in 
this lab. The Internet connection and router can be real or not; this does not affect the 
configuration of the router. 


Physical Layout and Prestaging 


e Connect the hubs and serial cables to the routers, as shown in Figure 12-14. 


Configure an additional router to serve as the connection to the Internet. This is totally 
optional. 

e A Frame Relay switch with three PVCs also is required. Example 12-32 lists the Frame 
Relay configuration used in this lab. 


Example 12-32 Frame Relay Switch Configuration 


hostname frame_switch 

! 

frame-relay switching 

! 

<<<text omitted>>> 

! 

interface Serial0 

no ip address 

encapsulation frame-relay 

no fair-queue 

clockrate 148000 

frame-relay intf-type dce 

frame-relay route 111 interface Seriall 110 
frame-relay route 121 interface Serial3 102 
frame-relay route 150 interface Serial5 151 
! 

interface Seriall 

no ip address 

encapsulation frame-relay 

clockrate 148000 

frame-relay intf-type dce 

frame-relay route 110 interface SerialO 111 
! 

interface Serial2 

no ip address 

shutdown 

! 
interface Serial3 

no ip address 

encapsulation frame-relay 
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clockrate 64000 

frame-relay intf-type dce 

frame-relay route 102 interface SerialO 121 
! 
interface Serial5 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay intf-type dce 

frame-relay route 151 interface SerialO 150 
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Lab 24: OSPF Multiple Area Routing, Authentication, Path 
Manipulation, Default Routing—Part Il 


Lab Walkthrough 


Configure the Frame Relay switch and attach the four routers in a back-to-back manner to 
the Frame switch. Use V.35 cables or CSU/DSUs with crossover cables to connect the routers. 
Create the three LANs by the use of switches or hubs/MAUs, as illustrated in Figure 12-14. 


When the physical connections are complete, assign IP addresses to all LAN and WAN 
interfaces, as depicted in Chapter 5. Example 12-33 lists the Frame Relay configurations, to 


this point, on all routers involved. 


Example 12-33 Frame Relay Configurations 


hostname dental_ho 
! 
<<<text omitted>>> 
! 
interface Serial0 
no ip address 
encapsulation frame-relay 
frame-relay lmi-type cisco 
! 
interface Serial0O.1 multipoint 
ip address 172.16.1.5 255.255.255.0 
frame-relay map ip 172.16.1.6 121 broadcast 
frame-relay map ip 172.16.1.1 111 broadcast 
! 
interface Serial0.2 point-to-point 
ip address 172.16.2.5 255.255.255.252 


frame-relay interface-dlci 150 
! 


hostname crowns 
! 
<<<text omitted>>> 
! 
interface Serial0 
ip address 172.16.1.6 255.255.255.0 
no ip directed-broadcast 
encapsulation frame-relay 
no ip mroute-cache 
frame-relay map ip 172.16.1.5 102 broadcast 
frame-relay map ip 172.16.1.1 102 broadcast 
frame-relay lmi-type cisco 


hostname root_canals 

! 

interface Serial0d 

ip address 172.16.1.1 255.255.255.0 
encapsulation frame-relay 
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no ip mroute-cache 

frame-relay map ip 172.16.1.5 110 broadcast 
frame-relay map ip 172.16.1.6 110 broadcast 
! 


hostname fillings 

! 

<<<text omitted>>> 

! 

interface Serial0d 

no ip address 

encapsulation frame-relay 
frame-relay lmi-type cisco 

! 

interface Serial0.1 point-to-point 
ip address 172.16.2.6 255.255.255.252 
frame-relay interface-—dlci 151 

! 


After the LAN and WAN interfaces are configured and basic IP connectivity is established, you 
can begin to configure OSPF. Recalling the detailed process to configure OSPF, you have the 
following: 


Step 1. Perform area design and DR/BDR designation. 


Step 2. Assign RIDs with the use of loopback on routers running Cisco |OS Software 
Release 12.0 or earlier. 


Step 3. Enable OSPF, and assign RIDs on routers running Cisco |OS Software Release 
12.0 or later. 


Step 4. Configure OSPF interfaces. 
Step 5. Configure additional neighbor support, if required. 
Step 6. Configure OSPF area types. 


Step 7. Configure other OSPF parameters, such as authentication. 


Step 1 involves area design. In this model, we put the LAN network between crowns, 
root_canal and pain_center in OSPF Area 200. Area 200 also will have Type 2 authentication. 
The fillings router will be in an NSSA area. The multipoint Frame Relay network and the LAN 
network of dental_ho will reside in Area 0. The dental_ho router should be DR for the Frame 
Relay multipoint network because it is the only router with a PVC directly to the crowns and 
root_canal routers. 


Step 2 involves setting RIDs on the routers that have Cisco |OS Software prior to Release 
12.0. To accomplish this, use loopback interfaces on those routers. Figure 12-15 shows the 
diagram with the router IDs and areas that we have assigned. 


Figure 12-15. Dr. Stai's Dental Network with RI Ds 
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Step 3 is where the real configuration begins. On all the routers, enable OSPF in AS 2002 
with the command router ospf 2002. On routers that have Cisco |OS Software Release 
12.0, use the router command router-id ip address to assign the static RIDs to the routers. 


At Step 4, you configure which interfaces will participate in OSPF routing and what areas they 
will reside in. On the dental_ho router, the EO interface will be in Area 0, along with the s0.1 
multipoint interface. The s0.2 interface will be in Area 10. Example 12-34 lists the OSPF 


configuration, to this point, of the router dental_ho. 


Example 12-34 Preliminary OSPF Configuration of dental_ ho 


router ospf 2002 

router-id 192.168.200.200 

network 128.10.1.5 0.0.0.0 area 0 
network 172.16.1.5 0.0.0.0 area 0 


network 172.16.2.5 0.0.0.0 area 10 
! 


Recall from previous sections that a wildcard mask of 0.0.0.0 means match every octet of the 
address. In this OSPF configuration, you are telling the router to put only a single interface 
into an area. 
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The preliminary OSPF configurations on the crowns, root_canals, and pain_center routers will 
resemble each other. The routers that have an SO interface will be in Area 0, while the LAN 
interfaces will reside in Area 200. The preliminary OSPF configuration for the crowns router is 
represented in Example 12-35. 


Example 12-35 Preliminary OSPF Configuration of the crowns Router 


router ospf 2002 
router-id 192.168.200.6 
network 172.16.1.6 0.0.0.0 area 0 


network 172.16.10.6 0.0.0.0 area 200 
! 


The fillings router will have both interfaces in Area 10. Because this router will not need any 
additional neighbor support, you can skip Step 5 for this router and configure the area as an 
NSSA area. Example 12-36 lists the OSPF configuration of the fillings router. 


Example 12-36 Preliminary OSPF Configuration of the fillings Router 


router ospf 2002 
router-id 192.168.200.3 
area 10 nssa 
network 172.16.2 


network 172.16.3. 
! 
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Step 5 requires you to configure the additional neighbor support needed for OSPF to form an 
adjacency over the Frame Relay multipoint network. For the adjacency to form properly, set 
the priority of the dental_ho router to be 255 and the priority of the crowns and root_ canals 
to 0. You also will add neighbor statements to the routers. Example 12-37 lists the 


configuration of the crowns and dental_ho routers. 


Example 12-37 OSPF Configuration of the crowns and dental_ ho 
Router 


! 
interface Serial0 

no ip address 

encapsulation frame-relay 

frame-relay lmi-type cisco 

! 
interface Serial0O.1 multipoint 

ip address 172.16.1.5 255.255.255.0 

ip ospf priority 255 

frame-relay map ip 172.16.1.6 121 broadcast 
frame-relay map ip 172.16.1.1 111 broadcast 
! 

interface Serial0.2 point-to-point 

ip address 172.16.2.5 255.255.255.252 
frame-relay interface-dlci 150 

! 

interface Seriall 
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no ip address 

shutdown 

! 

interface BRIO 

no ip address 

shutdown 

! 
router ospf 2002 
router-id 192.168.200.200 
area 10 


network 128.10.1.5 0.0.0.0 area 0 
network 172.16.1.5 0.0.0.0 area 0 
network 172.16.2.5 0.0.0.0 area 10 


neighbor 172.16.1.1 
neighbor 172.16.1.6 


Step 6 of the configuration involves only the dental_ho and fillings router. This step requires 
you to configure Area 10 as an NSSA area. To configure the area as an NSSA area, simply 
append that NSSA argument into the area statements. Both routers dental_ho and fillings 
will need NSSA areas configured. Example 12-38 lists the OSPF configuration of the fillings 


router. 


Example 12-38 OSPF NSSA Configuration on fillings 


! 
router ospf 2002 
router-id 192.168.200.3 
area 10 nssa 

network 172.16. 


2. 
network 172.16.3. 
! 


WO 


At this point, OSPF is fully operational, and you have IP connectivity to every router in the 
network. To verify this, we can examine the neighbors and the route table, and you can 
perform standard ping tests. To verify the NSSA area, use the show ip ospf command. 
Example 12-39 lists the output of the show ip ospf neighbor and show ip ospf commands 


on the dental_ho router. 


Example 12-39 Verify OSPF Operation and NSSA Configuration 


dental_ho#show ip ospf neighbor 


Neighbor ID Pri State Dead Time Address Interface 
192.168.2001 0 FULL/DROTHER 00:01:42 IZ 616. LoL Serial0d.1 
192.168. 200..6 0 FULL/DROTHER 00:01:44 WIZ A616 Serial0d.1 
192.168 .200.3 al FULL/ - 00:00:38 UTZ 6.2236 Serial0d.2 


dental_ho# 
dental_ho#show ip ospf 
Routing Process "ospf 2002" with ID 192.168.200.200 
Supports only single TOS(TOSO) routes 
<<<text omitted>>> 
Area 10 
Number of interfaces in this area is 1 


It is a NSSA area 
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Perform type-7/type-5 LSA translation 
generates NSSA default route with cost 1 
Area has no authentication 

SPF algorithm executed 11 times 

Area ranges are 

Number of LSA 6. Checksum Sum 0x30908 
Number of opaque link LSA 0. Checksum Sum 0x0 
Number of DCbitless LSA 0 

Number of indication LSA 0 

Number of DoNotAge LSA 0 

Flood list length 0 


dental_ho# 


The final step in the model calls for you to configure three things: a default route, 
authentication, and path selection. First, to configure a default route, you need to flag or 
mark a network as a default and then propagate it within the OSPF domain. To flag a route 
as a default network without using a static route, use the global command default-network 
128.10.1.0. To propagate the network, use the OSPF command default-information 
originate always. Remember, for a router to forward packets to a default route, all routers 
also need the global command ip classless enabled. A default route will not automatically 
get flooded into a NSSA area. For the NSSA area to receive a default route, the argument 
default-information-originate must be appended to the area 10 nssa router statement. 
Example 12-40 lists the configuration of dental_ho, highlighting the default routing 


commands. 


Example 12-40 Configuration of dental_ho 


router ospf 2002 
router-id 192.168.200.200 


network 128.10.1.5 0.0.0.0 
network 172.16.1.5 0.0.0.0 area 0 
network 172.16.2.5 0.0.0.0 
neighbor 172.16.1.1 

neighbor 172.16.1.6 


To verify that the default route is being propagated, list the route table of any router, 
excluding dental_ho router. Look for a gateway of last resort to be set and a route marked by 
an *, indicating that it is the candidate default. Example 12-41 lists the route table of the 
router fillings. Notice that the route is advertised to an NSSA area as an OSPF NSSA external 
Type 2 route. 


Example 12-41 Route Table of fillings 


fillings#show ip route 

Codes: C - connected, S - static, I - IGRP, R - RIP, M —- mobile, B - BGP 
D — EIGRP, EX -— EIGRP external, O — OSPF, IA — OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 


i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area 
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* — candidate default, U - per-user static route, o — ODR 
P —- periodic downloaded static route 


172.16.0.0/16 is variably subnetted, 4 subnets, 3 masks 


O IA 172.16.10.0/28 [110/138] via 172.16.2.5, 00:09:18, Serial0O.1 

Cc 172.16.2.4/30 is directly connected, Serial0O.1 

O IA 172.16.1.0/24 [110/128] via 172.16.2.5, 00:09:18, Serial0O.1 

c 172.16.3.0/24 is directly connected, TokenRing0O 
128.10.0.0/24 is subnetted, 1 subnets 

O IA 128210 .1.0 [110/741] vita 172.16.2.5, OOS09TLS, Serialo.t 

fillings# 


Next, you need to configure Type 2 or MD5 authentication on Area 200. You will need to 
enable authentication on the OSPF area statement and on the interface. Use cisco as the MD5 
password. Example 12-42 lists the configuration needed for authentication on the 


pain_center router. The configuration must be identical on all the routers in Area 200. 


Example 12-42 MD5 Authentication on the Router pain_ center 


interface Ethernet0O 
ip address 172.16.10.8 255.255.255.240 
ip ospf message-digest-—key 1 md5 cisco 
! 
<<<text omitted>>> 
! 
router ospf 2002 
network 172.16.10.8 0.0.0.0 area 200 
area 200 authentication message-digest 


As you enable authentication throughout Area 200, routes and neighbors will start to age out 
and disappear. This is one obvious way to tell you that authentication is starting to work. 
Performing the show ip ospf command also lists the area as being authenticated. When all 
the routers have authentication enabled, neighbors and routes will start to reappear. 


The final portion of the lab, excluding the optional part, involves influencing packets from the 
pain_center router. Traffic from this router should always take a primary path through the 
root_canals router. A quick view of the route table on pain_center shows two paths to the 
other portions of the network. One path goes through the root_canals router, and one goes 
through the crowns router, such as in Example 12-43. 


Example 12-43 Route Table of pain_ center 


pain_center#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M —- mobile, B - BGP 
D — EIGRP, EX -— EIGRP external, O — OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U -— per-user static route, o —- ODR 
Gateway of last resort is 172.16.10.1 to network 0.0.0.0 
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128.10.0.0/24 is subnetted, 1 subnets 


O IA 128.10.1.0 [110/84] via 172.16.10.1, 00:14:03, Ethernet0 
[110/784] vie 172.136.1036, C0t14:03> Ethernétd 
Cc 192.168.200.0/24 is directly connected, Loopback0 
172.16.0.0/16 is variably subnetted, 4 subnets, 3 masks 
c 172.16.10.0/28 is directly connected, Ethernet0O 
O IA 172.16.2.4/30 [110/138] via 172.16.10.1, 00:14:03, Ethernet0 


110/138] via 172.16.10.6, 00:14:03, Ethernet0O 


O TA 72.161 .0/24 (10/74) vee 72.16.1021, 004203, BEherneto 
110/74) wie L72.16.10.6, 00214503, Ethernét0 
O IA 172.16:3.0/24 [110/144] via 172.16.10.1, 0Or1l4:s04, Ethernet 0 


110/144] via 172.16.10.6, 00:14:04, Ethernet0 
OFB2 0.0.0.0/0 [1L10/1] via 172.16.10.1, 00:14204, Hthernetd 

[2110/1] via 172.16.10.6, O00814:04, Ethernetd 
pain_center# 


OSPF will load-balance over these routes, but instead you want to use only one route. If the 
primary route becomes available, OSPF will use the backup route through the crowns router. 
To influence the forwarding decisions of the router, you can use the bandwidth command to 
change the cost of the link or you can directly change the cost with the interface command ip 
ospf cost. You could influence the forwarding decision in this model in many ways. The 
method that you will use here is to simply set the OSPF cost of the sO interface of the 
root_canals router to 15. Example 12-44 shows the route table, followed by a trace 
performed on the pain_center after the change has been made to the root_canals router. 
Notice that only one primary path, through 172.16.10.1, shows up in the route table. 


Example 12-44 Route Table of pain_ center Router 


pain_center#show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 
D — EIGRP, EX -— EIGRP external, O -— OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U - per-user static route, o —- ODR 


Gateway of last resort is 172.16.10.1 to network 0.0.0.0 


128.10.0.0/24 is subnetted, 1 subnets 


O IA 128.10.1.0 [110/35] via 172.16.10.1, 00:00:17, Ethernet0 

Cc 192.168.200.0/24 is directly connected, Loopback0 
172.16.0.0/16 is variably subnetted, 4 subnets, 3 masks 

Cc 172.16.10.0/28 is directly connected, Ethernet0O 

O ITA L723:16.2.4/730 [110/89] via 172.16.10.1, 002700817, Ethernet) 

O IA 172.16.1.0/24 [110/25] via 172.16.10.1, 00:00:17, Ethernet0 

O IA 172.16<3..0/24. [110/95] vie 172.162310.1,. 00200217, Bthernet0 


OFE2 -0..0.0.070- [1210/1] via 172.126.1061, 00:00¢17, Hthernetd 
pain_center#trace 128.10.1.5 


Typ scape sequence to abort. 
Tracing the route to 128.10.1.5 


1 172.16.10.1 0 msec 0 msec O msec 


2 172.16.1.5 16 msec 24 msec * 
pain_center# 
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The optional portion of the lab instructs you to propagate the default route only if the 
network 128.10.1.0/24 is in the route table. If the network 128.10.1.0 is not available, the 
router dental_ho should not propagate the default route to the rest of the OSPF domain. To 
accomplish this, you need to configure what is called a conditional default route. To configure 
a conditional default route (refer to Example 12-45), call a route map on the default- 
information originate command. This route map, in turn, matches a prefix list that 
corresponds to the network 128.10.1.0. 


Example 12-45 Conditional Default Route Configuration 


! 

router ospf 2002 

router-id 192.168.200.200 

area 10 nssa default-—information-originate 
network 128.10.1.5 0.0.0.0 area 0 

network 172.16.1.5 0.0.0.0 area 0 

network 172.16.2.5 0.0.0.0 area 10 
neighbor 172.16.1.6 

neighbor 172.16.1.1 


-“default-information originate always route-map condition —? calls route map 
! 

ip classless 

ip default-network 128.10.0.0 

no ip http server 

! 

! 


ip prefix-list cond seq 5 permit 128.10.1.0/24 © —?match route 128.10.1.0/24 
BOE S ea pr cons one esi rid 

“match ip address prefix-list cond = = =)" call prefix-list called "cond" 
! 


When the Ethernet interface is shut down, the dental_ho router no longer advertises the 
default route. Because the NSSA default route is controlled differently, you cannot call a 
route map and control default routing to the NSSA area. Future Cisco |OS Software releases 
might provide for this. 


Example 12-46 lists the relevant portions of the routers in the lab. 


Example 12-46 Router Configurations Used in This Lab 


hostname dental_ho 
! 
interface Ethernet0O 
ip address 128.10.1.5 255.255.255.0 
! 
interface Serial0O.1 multipoint 
ip address 172.16.1.5 255.255.255.0 
ip ospf priority 255 
frame-relay map ip 172.16.1.6 121 broadcast 


frame-relay map ip 172.16.1.1 111 broadcast 
! 
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interface Serial0.2 point-to-point 
ip address 172.16.2.5 255.255.255.252 
frame-relay interface-dlci 150 
! 
<<<text omitted>>> 
! 
router ospf 2002 
router-id 192.168.200.200 
area 10 nssa default-information-originate 
network 128.10.1.5 0.0.0.0 area 0 
network 172.16.1.5 0.0.0.0 area 0 
network 172.16.2.5 0.0.0.0 area 10 
neighbor 172.16.1.6 
neighbor 172.16.1.1 
default-information originate always route-map condition 
! 
ip classless 
ip default-network 128.10.0.0 
no ip http server 
! 
ip prefix-list cond seq 5 permit 128.10.1.0/24 
route-map condition permit 10 
match ip address prefix-list cond 
! 
! 


hostname crowns 
! 
interface Ethernet0 
ip address 172.16.10.6 255.255.255.240 
no ip directed-broadcast 
ip ospf message-digest-key 1 md5 cisco 
! 
interface Serial0 
ip address 172.16.1.6 255.255.255.0 
no ip directed-broadcast 
encapsulation frame-relay 
ip ospf priority 0 
no ip mroute-cache 
frame-relay map ip 172.16.1.5 102 broadcast 
frame-relay map ip 172.16.1.1 102 broadcast 
frame-relay lmi-type cisco 
! 
router ospf 2002 
router-id 192.168.200.6 
area 200 authentication message-digest 
network 172.16.1.6 0.0.0.0 area 0 
network 172.16.10.6 0.0.0.0 area 200 
! 
ip classless 
! 
! 


hostname root_canals 
! 
interface LoopbackO 
ip address 192.168.200.1 255.255.255.0 
! 
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<<<text omitted>>> 
! 
interface Ethernet2 
ip address 172.16.10.1 255.255.255.240 
ip ospf message-digest-—key 1 md5 cisco 
media-type 10BaseT 
tt 
interface Serial0 
ip address 172.16.1.1 255.255.255.0 
encapsulation frame-relay 
ip ospf cost 15 
ip ospf priority 0 
no ip mroute-cache 
frame-relay map ip 172.16.1.5 110 broadcast 
frame-relay map ip 172.16.1.6 110 broadcast 
! 
<<<text omitted>>> 
! 
router ospf 2002 
network 172.16.1.1 0.0.0.0 area 0 
network 172.16.10.1 0.0.0.0 area 200 
area 200 authentication message-digest 
! 
ip classless 
! 
! 


hostname pain_center 
! 
interface LoopbackO 
ip address 192.168.200.8 255.255.255.0 
! 
interface Ethernet0 
ip address 172.16.10.8 255.255.255.240 
ip ospf message-digest-key 1 md5 cisco 
! 
<<<text omitted>>> 
! 
router ospf 2002 
network 172.16.10.8 0.0.0.0 area 200 
area 200 authentication message-digest 
! 
ip classless 
! 
! 


hostname fillings 

! 

interface Serial0 

no ip address 

encapsulation frame-relay 
frame-relay lmi-type cisco 

! 

interface Serial0.1 point-to-point 
ip address 172.16.2.6 255.255.255.252 
frame-relay interface-—dlci 151 

! 

interface TokenRingO 
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ip address 172.16.3.3 255.255.255.0 
ring-speed 16 

! 
router ospf 2002 

router-id 192.168.200.3 

area 10 nssa 
network 172.16.2. 
network 172.16.3. 
! 


W Oo 


ip classless 
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Lab 25: OSPF Multiple Area Routing, Route Redistribution and 
Summarization—Part | 


Practical Scenario 


As OSPF networks continue to grow, it becomes inevitable that the network will be broken into 
areas. Redistribution between routing protocols is also fairly common. When integrating a classful 
routing protocol with a classless routing protocol, an understanding of summarization is required. 
The following lab gives you practice in configuring multiple OSPF areas, virtual links, 
redistribution, and summarization. 


Lab Exercise: 


The Herpetology (Herp) Information Network or HIN, is a network of herpetologists exchanging 
biological and ecological information on several species of reptiles and amphibians. HIN has a 
Frame Relay network used to disperse information across the country. The network is in a 
constant state of flux and suffers from this continuous change. You have been given the task of 
fixing the current OSPF network and integrating it with an |GRP network. You must abide by the 
following design guidelines: 


e Configure an |P network as depicted in Figure 12-16, by using OSPF as the routing 
protocol and 2001 as the Autonomous System ID. 


Figure 12-16. HIN 


812 


Herp Information 


i i 
i i 
Network (HIN) ! 
OSPF Autonomous : 
System 2007 
$0.1 poini-bo-posnt 
IPetO.1, 1281/24 IPs10.1.1390, 1/24 
SOF poirit bee peoint 
50.1 & S02 are point-to-point IPat0.1.129. 1/24 iT 
noes Iain area) ——__ etic ta . IGRP * 


—~- 
i | 


Pa 
$6.1 point-io-spoint > = 


IP=10.1.128.224 _ 


30.1 point-io-paint me f 
IP=10.1. 129, Ved Ma a 


—seee & 


A bos 
IP=10.1.80.1/24 64 kbps -DCE \ og 


$1 
HDLC 
[P2101 ,60 24 = 
OSPF — Ff 
Tlie 75 r, 


e Configure the entire Frame Relay network as three point-to-point networks, as depicted in 
the figure. 

e Configure all the OSPF areas as denoted in the figure. The two Frame Relay point-to-point 
networks, between hin_hq, gecko, and tree_frog are in OSPF Area 0. The LAN interface of 
gecko is in OSPF Area 10, while the LAN interfaces of tree_frog and python are in OSPF 
Area 20. The serial interface of the python router and all the interfaces of the boa router 
are in OSPF Area 75. 

e Configure the Frame Relay point-to-point network between hin_hq and the chameleon 
router to be in the IGRP routing domain. Ensure full |P connectivity from the chameleon 
routers LAN interface to all of the OSPF networks and interfaces. 

e Configure three loopback interfaces on the chameleon router, and advertise this as a 
single OSPF route. 

e The gecko router must not have IP visibility to the LAN network on the boa router. 


Lab Objectives 


e Configure the HIN as depicted in Figure 12-16. Configure IP as denoted in the diagram. 
The LAN topology type is not important in this lab. 

e Use the Frame Relay data link protocol on the WAN. Use only point-to-point networks as 
indicated on the diagram. 

e Ensure full 1P connectivity to all IP interfaces—that is, be sure that you can ping all Frame 
Relay and LAN interfaces from all routers. You might not use any static routes. 

e Do not change the default OSPF network type. 

e Configure the |GRP domain on the chameleon router. Ensure that this domain has full IP 
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reachability to the entire OSPF network. 
e Configure and advertise three loopback networks on the chameleon router. These 


networks are 10.1.16.0/24, 10.1.17.0/24, and 10.1.18.0/24. Aggregate the networks into 


a single OSPF route. 

e Prevent the gecko router from reaching the network 10.1.70.1/24. 

e (Optional) Configure OSPF so that the tree_frog router will send OSPF hellos every 30 
seconds. 


Equipment Needed 


e Seven Cisco routers. Four will be connected through V.35 back-to-back cables or ina 
similar manner to a Frame Relay switch. 

e Two routers will be connected directly through V.35 back-to-back cables or in a similar 
manner. 

e Five LANs segments, provided through hubs or switches. The LAN topology is not 
significant to this lab. 


Physical Layout and Prestaging 


e Connect the hubs and serial cables to the routers, as shown in Figure 12-16. 
e A Frame Relay switch with three PVCs also is required. Example 12-47 lists the Frame 


Relay configuration used in this lab. Note that this is the same Frame Relay switching 
configuration as in the previous lab exercise. 


Example 12-47 Frame Relay Switch Configuration 


hostname frame_switch 

! 

frame-relay switching 

! 

<<<text omitted>>> 

! 

interface Serial0 

no ip address 

encapsulation frame-relay 

no fair-queue 

clockrate 148000 

frame-relay intf-type dce 

frame-relay route 111 interface Seriall 110 
frame-relay route 121 interface Serial3 102 
frame-relay route 150 interface Serial5 151 
! 

interface Seriall 

no ip address 

encapsulation frame-relay 

clockrate 148000 

frame-relay intf-type dce 

frame-relay route 110 interface SerialO 111 
! 

interface Serial2 

no ip address 

shutdown 

! 
interface Serial3 

no ip address 

encapsulation frame-relay 

clockrate 64000 
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frame-relay intf-type dce 

frame-relay route 102 interface SerialO 121 
! 
interface Serial5 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay intf-type dce 

frame-relay route 151 interface SerialO 150 
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Lab 25: OSPF Multiple Area Routing, Route Redistribution and 
Summarization—Part Il 


Lab Walkthrough 


Configure the Frame Relay switch and attach the four routers in a back-to-back manner to the 
Frame switch. Use V.35 cables or CSU/DSUs with crossover cables to connect the routers. 
Create the five LANs by the use of switches or hubs/MAUs, as illustrated in Figure 12-16. 


When the physical connections are complete, assign IP addresses to all LAN and WAN 
interfaces, as depicted in Figure 12-16. Configure three loopback addresses on the chameleon 
router with the addresses 10.1.16.0/24, 10.1.17.0/24, and 10.1.18.0/24. Be sure that you can 
ping each router's local LAN and WAN interface before continuing. You will use frame-relay 
interface-dlici commands on all of the point-to-point interfaces. Example 12-48 lists the Frame 
Relay configurations, to this point, on all routers involved. 


Example 12-48 Frame Relay Configurations 


hostname hin_hq 

! 

<<<text omitted>>> 

! 

interface Serial0O 

no ip address 

encapsulation frame-relay 

! 

interface Serial0.1 point-to-point 
ip address 10.1.128.1 255.255.255.0 
frame-relay interface-dlci 121 

! 

interface Serial0.2 point-to-point 
ip address 10.1.129.1 255.255.255.0 
frame-relay interface-dlci 111 

! 

interface Serial0.3 point-to-point 
ip address 10.1.130.1 255.255.255.0 


frame-relay interface-dlci 150 
! 


hostname gecko 
! 
<<<text omitted>>> 
! 
interface Serial0O 
no ip address 
no ip directed—-broadcast 
encapsulation frame-relay 
no ip mroute-cache 
frame-relay lmi-type cisco 
! 
interface Serial0.1 point-to-point 
ip address 10.1.128.2 255.255.255.0 
no ip directed—-broadcast 
frame-relay interface-dlci 102 
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hostname tree_frog 

! 

interface Serial0O 

no ip address 

encapsulation frame-relay 

no ip mroute-cache 

! 

interface Serial0.1 point-to-point 
ip address 10.1.129.2 255.255.255.0 
frame-relay interface-dlci 110 

! 


hostname chameleon 

! 

<<<text omitted>>> 

! 

interface Serial0O 

no ip address 

encapsulation frame-relay 
frame-relay lmi-type cisco 

! 

interface Serial0.1 point-to-point 
ip address 10.1.130.2 255.255.255.0 


frame-relay interface-dlci 151 
! 


To configure the WAN network between python and the boa, one end will need to be configured 
for clocking, or DCE. Example 12-49 lists the serial configuration of the boa router, which is the 


DCE side of the link. This is not necessary if you are using CSU/DSUs with crossover cables. 


Example 12-49 Serial Configuration of the Router boa 


interface Seriall 
ip address 10.1.80.2 255.255.255.0 
clockrate 56000 


After the LAN and WAN interfaces have been configured and basic IP connectivity has been 
established, begin to configure OSPF and IGRP. First, you will configure OSPF, and then you will 
integrate it with IGRP. Recalling the detailed process to configure OSPF, you have the following: 


Step 1. Perform area design, DR/BDR designation. 


Step 2. Assign RIDs with the use of loopback on routers prior to Cisco 1|OS Software 
12.0. 


Step 3. Enable OSPF, and assign RIDs on routers running Cisco |OS Software Release 
12.0 and later. 


Step 4. Configure OSPF interfaces. 
Step 5. Configure additional neighbor support, if required. 
Step 6. Configure OSPF area types and virtual links. 


Step 7. Configure other OSPF parameters, such as summarization and redistribution. 
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Step 1 involves area design. In this model, the Frame Relay point-to-point networks are in OSPF 
Area 0. The LAN interface of the gecko router is in OSPF Area 10, while the LAN interfaces of the 
tree_frog and python routers are in OSPF Area 20. The serial interface of the python router and 
all the interfaces of the boa router are in OSPF Area 75. As you probably can tell at this point, 
you will need a virtual link to connect Area 75 to the rest of the OSPF network. 


Step 2 involves setting RIDs on the routers that have Cisco |OS Software prior to Release 12.0. 
To accomplish this, you will use loopback interfaces on those routers. Figure 12-17 shows the 
diagram with the router |Ds that you have assigned and the virtual link marked. 


Figure 12-17. HIN with RI Ds Assigned 
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Again, Step 3 is where the real configuration begins. On all the routers except chameleon, you 
will enable OSPF in AS 2001 with the command router ospf 2001. On routers that have Cisco 
10S Software Release 12.0, use the router command router-id ip address to assign the static 
RIDs to the routers. 


Step 4 involves configuring which interfaces will participate in OSPF routing and the areas in 
which they will reside. On the hin_hq router, the EO interface will be in Area 0, along with the 
s0.1 and sO.2 point-to-point interfaces. Example 12-50 lists the OSPF configuration, to this 
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point, of the router hin_hq. 


Example 12-50 Preliminary OSPF Configuration of hin_hq 


router ospf 2001 

router-id 192.168.200.5 

redistribute igrp 2001 subnets tag 5 
network 10.1.5.1 0.0.0.0 area 0 
network 10.1.128.1 0.0.0.0 area 0 
network 10.1.129.1 0.0.0.0 area 0 
default-metric 64 


The network statements in the previous example could be simplified with one command— 
network 10.1.0.0 0.0.255.255 area QO. !n production networks, it pays to be specific on the 
mask. As changes occur in the network, new interfaces in different areas might be added. If the 
wildcard mask is too general, OSPF will have to be interrupted while new, more specific 
network statements are configured. 


The LAN interface of the gecko router resides in OSPF Area 10, while its serial interface resides 
in OSPF Area 0. The tree_frog routers LAN interface resides in OSPF Area 20, while its serial 
interface also resides in OSPF Area 0. Example 12-51 presents the preliminary OSPF 


configurations for the gecko and tree_frog routers. 


Example 12-51 Preliminary OSPF Configurations of the gecko and 
tree_ frog Routers 


hostname gecko 
! 
router ospf 2001 
router-id 192.168.200.6 
network 10.1.6.1 0.0.0.0 area 10 
network 10.1.128.2 0.0.0.0 area 0 
! 


hostname tree_frog 
! 

router ospf 2001 
network 10.1.1. 


1 
network 10.1.129. 
! 


area 20 
.0 area 0 


NO 


NOTE 


The tree_frog router does not show a router ID because it is using a loopback 
interface for its RID. The tree_frog router is running a Cisco |OS Software Release 
prior to 12.0. 


The python router will have one interface in Area 20 and one in Area 75, while the boa router 
will have both interfaces in Area 75. Example 12-52 lists the OSPF configuration of these routers. 
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Example 12-52 Preliminary OSPF Configuration of the python and boa 
Routers 


hostname python 
! 
router ospf 2001 
network 10.1.80.1 0.0.0.0 area 75 


network 10.1.1.2 0.0.0.0 area 20 
! 


hostname boa 
' 
router ospf 2001 


network 10.1.0.0 0.0.255.255 area 75 
! 


Step 5 requires you to configure the additional neighbor support. In this model, adjacencies 
automatically form over the Frame Relay point-to-point networks. No additional neighbor 
configuration support is needed. 


At this point, OSPF is operational, except for Area 75, and you have IP connectivity to every 
router in the network. To verify this, you can examine the neighbors and route table, as well as 
perform standard pings tests. Example 12-53 lists the output of the show ip ospf neighbor 


commands on the hin_hq, gecko, tree_frog, and python routers. 


Example 12-53 Verifying OSPF Neighbors 


hin_hq#show ip ospf neighbor 


Neighbor ID Pri. State Dead Time Address Interface 
192.168.200.6 a FULL/ - OOsF00235 MO et sl28s2 Serial0.1 
192.168.2001 al FULL/ - OOF00's32 WO 2 Os 2 Serial0.2 
hin_hq# 


tree_frog#show ip ospf neighbor 


Neighbor ID Pei State Dead Time Address Interface 
192.168.2008 1 FULL/DR 00:00:35 1O.121.2 Ethernet2 
192..168.200..5 al FULL/ - 00:00:34 LOT «129 oT. Serial0.1 
tree_frog# 


phython#show ip ospf neighbor 


Neighbor ID Pei. State Dead Time Address Interface 
192.168.200.1 1 FULL/BDR 00200339 a6 el ee eee Ethernet0O 
192..168.200..7 1 FULL/ - OG200235 IDL 280.2 Serialo 
python# 


Step 6 requires you to configure OSPF special areas, such as stub areas—or, in this case, virtual 
links. As mentioned previously, you will need a virtual link to connect Area 75 to the rest of the 
OSPF domain. To configure a virtual link, you need to locate the two routers that will serve as 
your endpoints for the virtual links. In this model, Area 20 will be your transit area; therefore, 
your virtual links need to be defined on the routers tree_frog and python. The syntax on the 
tree_frog router will be area 20 virtual-link 192.168.200.8, which is the RID of the python 
router. The python router, in turn, points to the RID of the tree_frog router. The syntax on the 
python router will be area 20 virtual-link 192.168.200.1. 
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Static router |Ds are vital to the operation of OSPF virtual circuits. If you have trouble bringing 
up the virtual link and have verified that there are no configuration errors, try reloading the 
routers. A common problem with virtual links is RIDs, and this will reassign them in routers 
running Cisco |OS Software prior to Release 12.0. To view whether the virtual link is working, 
use the show ip ospf virtual-link command. The routes from the boa router also should start 
appearing throughout the OSPF domain. Example 12-54 lists the output of the show ip ospf 


virtual-link command on the tree_frog router. 


Example 12-54 Verifying the Virtual Link 


tree_frog#show ip ospf virtual-links 
Virtual Link OSPF_VLO to router 192.168.200.8 is up 
Run as demand circuit 
DoNotAge LSA allowed. 
Transit area 20, via interface Ethernet2, Cost of using 10 
Transmit Delay is 1 sec, State POINT_TO_POINT, 
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 
Hello due in 00:00:00 
Adjacency State FULL (Hello suppressed) 
tree_frog# 


The OSPF domain is now fully functional. By viewing the route table on the boa router, you can 
see that you have routes to every destination in the network, as shown in Example 12-55. 


Example 12-55 Verifying the OSPF Domain 


boa#show ip route 
Codes: C -— connected, S -— static, I - IGRP, R —- RIP, M — mobile, B — BGP 
D — EIGRP, EX — EIGRP external, O — OSPF, IA —- OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * -— candidate default 
U - per-user static route, o — ODR 


Gateway of last resort is not set 


10.0.0.0/8 is variably subnetted, 8 subnets, 4 masks 


O IA L0.1%1.0/27 [110/74] via 10.1.80.1, 00:28:02, Seriall 

O IA 10.1.6.0/28 [110/212] via 10.1.80.1, 00:28:02, Seriall 

O IA L0.1.5.0/24 [110/148] via 10.1.80.1, 00528:02, Seriall 

Cc 10.1.70.0/24 is directly connected, Ethernet0 

Cc 10.1.80.0/24 is directly connected, Seriall 

O IA 10.1.129.0/24 [110/138] via 10.1.80.1, 00:28:02, Seriall 
O IA 10%1.128.0730 [110/266] via. 10.1.80.1, 00328302, Seriall 
O IA 10.1.128.0/24 [110/202] via 10.1.80.1, 00:28:02, Seriall 
Cc 192.168.200.0/24 is directly connected, Loopback0O 


a 
fe) 
o 
HE 


To integrate the IGRP domain, configure |GRP on the chameleon and hin_hq routers. Example 
12-56 lists the IGRP configuration on the hin_hq router. Be sure to use the passive-interface 


command to prevent unnecessary broadcast from the Ethernet and other serial interfaces. The 
IGRP configuration on hin_hg and chameleon will be identical. 


Example 12-56 Configuring |GRP on hin_hq 
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! 
router igrp 2001 
passive-interface Ethernet0O 
passive-interface Serial0.1 
passive-interface Serial0.2 


network 10.0.0.0 
! 


Next, you need to configure redistribution between IGRP and OSPF. There is only one 
redistribution point in the network, so you do not have to worry about route feedback or 
redistribution loops. Example 12-57 lists the configuration of the hin_hq router, highlighting the 
redistribution commands. In this example, you use an OSPF default metric of 64 because it is 
the cost of a Tl interface. You also use the subnet keyword to redistribute multiple subnets into 
OSPF. 


Example 12-57 Redistribution on the hin_hq Router 


! 
router ospf 2001 
router-id 192.168.200.5 


network 10.1.5.1 0.0.0.0 area 0 
network 10.1.128.1 0.0.0.0 area 0 
network 10.1.129.1 0.0.0.0 area 0 


! 
router igrp 2001 


passive-interface Ethernet0O 
passive-interface Serial0.1 
passive-interface Serial0.2 
network 10.0.0.0 


default-metric 1544 10 25411500 = *~ IGRP metric 


After redistribution is enabled, if you viewed the route table on the chameleon router, you would 
find the results in Example 12-58. 


Example 12-58 Route Table of the chameleon Router 


chameleon#show ip route 
Codes: C - connected, S —- static, I - IGRP, R —- RIP, M —- mobile, B — BGP 
D — EIGRP, EX — EIGRP external, O — OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area 
* — candidate default, U - per-user static route, o —- ODR 
P -— periodic downloaded static route 


Gateway of last resort is not set 


10.0.0.0/24 is subnetted, 10 subnets 
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Cc 10.1.3.0 is directly connected, TokenRing0O 

ih 10.1.5.0 [100/8576] via 10.1.130.1, 00:00:00, SerialO.1 

e 10.1.18.0 is directly connected, Loopback22 

e 10.1.17.0 is directly connected, Loopback21 

Cc 10.1.16.0 is directly connected, Loopback20 

I 10.1.70.0 [100/8486] via 10.1.130.1, 00:00:00, Serial0.1 

iT 10.1.80.0 [100/8486] via 10.1.130.1, 00:00:00, Serial0.1 

Cc 10.1.130.0 is directly connected, Serial0O.1 

I 10.1.129.0 [100/10476] via 10.1.130.1, 00:00:00, Serial0.1 
I L0ci.128...0 [200/10476] vie: 10.1.130.1;, 00200200, Seriald.1 


chameleon# 


At first glance, it might appear that the route table is complete; however, upon closer 
examination, two routes are missing: 10.1.6.0/28 and 10.1.1.0/27. This is because IGRP can 
receive only routes that are on the same bit boundary as the interface receiving the routes. For 
the chameleon router to receive all the OSPF routes, they must be summarized on a 24-bit 
boundary that matches the bit boundary on its sO.1 interface. To summarize Area 20 and Area 
10, use the router command area x range statements. The area range statement for the 
gecko router will be area 10 range 10.1.6.0 255.255.255.0, and the area range statement 
on the tree_frog router will be area 20 range 10.1.1.0 255.255.255.0. After adding the area 
range statements, the route table on the chameleon router now has all the routes to the OSPF 
domain, as verified by Example 12-59. 


Example 12-59 Route Table of the chameleon Router 


chameleon#show ip route 
Codes: C -— connected, S - static, I - IGRP, R —- RIP, M —- mobile, B —- BGP 
D — EIGRP, EX — EIGRP external, O — OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area 
* — candidate default, U - per-user static route, o — ODR 
P -— periodic downloaded static route 


Gateway of last resort is not set 
10.0.0.0/24 is subnetted, 12 subnets 
Cc 10.1.3.0 is directly connected, TokenRing0O 
i 10.1.1.0 [2100/8486] via 10.1.130.1, 00:00:28, Séeriald.1 
I 10.1.6.0 [100/8486] via 10.1.130.1, 00:00:28, Serial0.1 
I 10.1.5.0 [100/8576] via 10.1.130.1, 00:00:28, Serial0O.1 
Cc 10.1.18.0 is directly connected, Loopback22 
Cc 10.1.17.0 is directly connected, Loopback21 
€ 10.1.16.0 is directly connected, Loopback20 
T 10.1.70.0 [100/8486] via 10.1.130.1, 00:00:28, Serial0O.1 
I 10.1.80.0 [100/8486] via 10.1.130.1, 00:00:29, Serial0.1 
Cc 10.1.130.0 is directly connected, Serial0O.1 
il 10.1.4129..0 [100/10476] via 10.1.130.1,; 00200229, Serialo.1 
T 10.1.128.0 [100/10476] via 10.1.130.1, 00:00:29, Serial0.1 


chameleon# 


If you have not configured the loopback interfaces on the chameleon router, do so at this time. 
You want to configure the hin_hq router to advertise the routes 10.1.16.0/24, 10.1.17.0/24, 
and 10.1.18.0/24 as a single OSPF route. To summarize networks from another AS, use the 
OSPF command summary-address command. The aggregate address is 10.1.16.0 with a 
255.255.252.0 mask. Example 12-60 shows the OSPF configuration of hin_hq now. 
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Example 12-60 OSPF Configuration of hin_hq 


router ospf 2001 

router-id 192.168.200.5 
summary-address 10.1.16.0 255.255.252.0 
redistribute igrp 2001 subnets tag 5 
network 10.1.5.1 0.0.0.0 area 0 
network 10.1.128.1 0.0.0.0 area 0 
network 10.1.129.1 0.0.0.0 area 0 
default-metric 64 

! 
router igrp 2001 

redistribute ospf 2001 
passive-interface Ethernet0O 
passive-interface Serial0.1 
passive-interface Serial0.2 

network 10.0.0.0 

default-metric 1544 10 254 1 1500 


To view the summary route, list the route table on the boa router, as in Example 12-61. 


Example 12-61 Route Table of the boa Router, Highlighting the 
Summary Route 


boa#show ip route 

Codes: C -— connected, S -— static, I - IGRP, R —- RIP, M —- mobile, B — BGP 
D — EIGRP, EX — EIGRP external, O — OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 


i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * -— candidate default 

U - per-user static route, o — ODR 
Gateway of last resort is not set 

10.0.0.0/8 is variably subnetted, 12 subnets, 4 masks 

O E2 10.1.3.0/24 [110/64] via 10.1.80.1, 00:37:49, Seriall 
O IA 10.1.1.0/27 [110/74] via 10.1.80.1, 00:27:57, Seriall 
O IA 10.1.1.0/24 [110/84] via 10.1.80.1, 00227257, Seriall 
O IA 10.1.6.0/24 [110/212] via 10.1.80.1, 00:28:57, Seriall 
O IA L0.,1.5.0/24 [1107148] wia 10.1.80.1, 01513237, Seriall 
@ 10.1.70.0/24 is directly connected, Ethernet0 
Cc 10.1.80.0/24 is directly connected, Seriall 
O E2 1061.2130..0724 [110764] via 10.1.80.1, 00237250, Seriall 
O IA 10.1.129.0/24 [110/138] via 10.1.80.1, 01:13:37, Seriall 
O IA 1021%128.0/30 [110/266] via .10.1.80.1, 0121337, Seriall 
O IA LO0,12128.0/24 [110/202] via 10.12.80.1,; 01213237, Seriall 
Cc 192.168.200.0/24 is directly connected, Loopback0O 


The final portion of the lab calls for you to prevent the LAN network of the router boa, 
10.1.3.0/24, from the gecko router. To accomplish this, configure an inbound distribute list on 
the gecko router. Example 12-62 demonstrates configuration of the filter on the gecko router. 


Example 12-62 Configuring a Distribute List on gecko 
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gecko (config) #router ospf 2001 


‘applied to s0.1 
gecko (config-router) #exit 
*~ deny 10.1.70.0/24 
gecko (config) #access-list 10 permit any 
gecko (config) # 


To verify the access list, clear the route table on the gecko router and then relist it. Example 12- 
63 lists the route table of gecko after the distribute list is applied. 


Example 12-63 Route Table on gecko 


gecko#show ip route 
Codes: C - connected, S —- static, I - IGRP, R —- RIP, M —- mobile, B — BGP 
D — EIGRP, EX — EIGRP external, O — OSPF, IA - OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i —- IS-1IS, Li = I8S-IS level-1, L2 - IS=1IS level=2, ia —- IS-IS. inter area 
* — candidate default, U - per-user static route, o — ODR 
P -— periodic downloaded static route 


Gateway of last resort is not set 

10.0.0.0/8 is variably subnetted, 11 subnets, 5 masks 
O E2 10.1.3.0/24 [110/64] via 10.1.128.1, 00:00:03, Serial0.1 
O IA LO.d 3120/27 [110/148] wie 10.1.128.1, 00:00703, Serial. 
O IA 10.12.1..0/724 [110/138] waa 10.1.128.1, 00:00:03, Serial0.1 
Cc 10.1.6.0/28 is directly connected, Ethernet0 
) 10.1.5.0/24 [110/74] via 10.1.128.1, 00:00:04, Serial0.1 
O E2 1051.16.0/22 [110/64] via 10.1.128.1,;. 00:00:03, Serial0.1 
O IA 10.1.80.0/24 [110/202] via 10.1.128.1, 00:00:04, Serial0.1 
O E2 10.1.130.0/24 [110/64] via 10.1.128.1, 00:00:04, Serial0.1 
O 10.1.129.0/24 [110/128] via 10.1.128.1, 00:00:04, Serial0.1 
O 10.1.128.0/24 [110/128] via 10.1.128.1, 00:00:04, Serial0.1 
le 10.1.128.0/24 is directly connected, Serial0.1 
gecko# 


The optional portion of the lab involves changing the hello interval on the tree_frog router. To 
perform this, you need to change the ip ospf hello-interval on the E2 interface of the 
tree_frog router. If you change the timer on just one interface, the neighbor soon will drop and 
routing will be compromised. Whenever changing timers in OSPF, be sure to change the timers 
on all routers on the same IP network. In this model, you have to change the timer on the 
tree_frog router and also on the python router. Example 12-64 demonstrates the timer 


configuration on the tree_frog router. 


Example 12-64 Changing the OSPF Hello Timer on an Interface 


tree_frog(config) #int e2 
tree_frog(config-if)#ip ospf hello-interval 30 
tree_frog(config-if) # 


To verify the timer change, check the status of the OSPF neighbors and perform the show ip 
ospf interface command on the interface. Example 12-65 lists the OSPF interface on ie 


tree_frog router with the new timer change. The OSPF dead timer and wait timer automatically 
are adjusted to four times the hello timer. 


Example 12-65 Viewing the OSPF Timer Change on tree_ frog 


tree_frog#show ip ospf interface e2 
Ethernet2 is up, line protocol is up 
Internet Address 10.1.1.1/27, Area 20 
Process ID 2001, Router ID 192.168.200.1, Network Type BROADCAST, Cost: 10 
Transmit Delay is 1 sec, State BDR, Priority 1 
Designated Router (ID) 192.168.200.8, Interface address 10.1.1.2 
Backup Designated router (ID) 192.168.200.1, Interface address 10.1.1.1 


Hello due in 00:00:11 
Neighbor Count is 1, Adjacent neighbor count is 1 
Adjacent with neighbor 192.168.200.8 (Designated Router) 
Suppress hello for 0 neighbor(s) 
tree_frog# 


Examples 12-66 concludes this lab walkthrough with the complete configurations of the routers 
used in the model of the HIN. 


Example 12-66 Final Configurations of the HIN 


hostname hin_hq 

! 

<<<text omitted>>> 

! 

interface Ethernet0O 

ip address 10.1.5.1 255.255.255.0 

! 

interface Serial0 

no ip address 

encapsulation frame-relay 

! 

interface Serial0.1 point-to-point 
ip address 10.1.128.1 255.255.255.0 
frame-relay interface-dlci 121 

! 

interface Serial0.2 point-to-point 
ip address 10.1.129.1 255.255.255.0 
frame-relay interface-dlci 111 

! 

interface Serial0.3 point-to-point 
ip address 10.1.130.1 255.255.255.0 
frame-relay interface-dlci 150 

! 

router ospf 2001 

router-id 192.168.200.5 
summary-address 10.1.16.0 255.255.252.0 
redistribute igrp 2001 subnets tag 5 
network 10.1.5.1 0.0.0.0 area 0 
network 10.1.128.1 0.0.0.0 area 0 
network 10.1.129.1 0.0.0.0 area 0 
default-metric 64 

! 


router igrp 2001 
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redistribute ospf 2001 

passive-interface Ethernet0O 
passive-interface Serial0.1 
passive-interface Serial0.2 


network 10.0.0.0 


default-metric 1544 10 254 1 1500 


! 
ip classless 
! 


hostname gecko 
! 


<<<text omitted>>> 
' 


interface Ethernet0 


ip address 10.1.6.1 255.255.255.240 
no ip directed-broadcast 


' 
interface SerialO 
no ip address 


no ip directed-—broadcast 
encapsulation frame-relay 


no ip mroute-cache 


frame-relay lmi-type cisco 


interface Serial0O.1 


point-to-point 


ip address 10.1.128.2 255.255.255.0 


frame-relay interface-dlci 102 


! 
<<<text omitted>>> 
! 

router ospf 2001 


router-id 192.168.200.6 


area 10 range 10.1 
network 10.1.6.1 0 
network 10.1.128.2 
distribute-list 10 
! 

ip classless 

! 


-6.0 255.255.255.0 
.0.0.0 area 10 
0.0.0.0 area 0 

in SerialO.1 


hostname tree_frog 
! 

interface LoopbackO 
ip address 192.168 
! 

interface Ethernet0 
no ip address 
shutdown 
media-type 10BaseT 
! 

interface Ethernetl 
no ip address 
shutdown 
media-type 10BaseT 
! 


interface Ethernet2 


-200.1 255.255.255.0 


ip address 10.1.1.1 255.255.255.224 
ip ospf hello-interval 30 
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media-type 10BaseT 
! 

interface Serial0O 
no ip address 


encapsulation frame-relay 


no ip mroute-cache 
! 
interface Serial0O.1 


point-to-point 


ip address 10.1.129.2 255.255.255.0 
frame-relay interface-dlci 110 


! 

<<<text omitted>>> 
! 

router ospf 2001 
network 10.1.1.1 0 
network 10.1.129.2 
area 20 range 10.1 


-0.0.0 area 20 


0.0.0.0 area 0 


-1.0 255.255.255.0 


area 20 virtual-link 192.168.200.8 


ip classless 
! 


hostname python 

! 

<<<text omitted>>> 
! 

interface LoopbackO 
ip address 192.168 
! 


interface Ethernet0 


-200.8 255.255.255.0 


ip address 10.1.1.2 255.255.255.224 
ip ospf hello-interval 30 


finterface Seriall 
ip address 10.1.80 
! 

<<<text omitted>>> 
! 

router ospf 2001 


-1 255.255.255.0 


network 10.1.80.1 0.0.0.0 area 75 


network 10.1.1.2 0 


-0.0.0 area 20 


area 20 virtual-link 192.168.200.1 


ip classless 
! 


hostname boa 

' 

<<<text omitted>>> 
' 

interface LoopbackO 
ip address 192.168 
' 

interface EthernetO 
ip address 10.1.70 
' 

interface Seriall 
ip address 10.1.80 
clockrate 56000 

' 


router ospf 2001 


-200.7 255.255.255.0 


-1 255.255.255.0 


-2 255.255.255.0 
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network 10.1.0.0 0.0.255.255 area 75 
' 

ip classless 

' 


hostname chameleon 
! 
<<<text omitted>>> 
! 
interface Loopback20 
ip address 10.1.16.1 255.255.255.0 
! 
interface Loopback21 
ip address 10.1.17.1 255.255.255.0 
! 
interface Loopback22 
ip address 10.1.18.1 255.255.255.0 
! 
interface Serial0O 
no ip address 
encapsulation frame-relay 
frame-relay lmi-type cisco 
! 
interface Serial0.1 point-to-point 
ip address 10.1.130.2 255.255.255.0 
frame-relay interface-dlci 151 
! 
interface TokenRingO 
ip address 10.1.3.1 255.255.255.0 
ring-speed 16 
! 
router igrp 2001 
network 10.0.0.0 
! 


ip classless 
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Chapter 13. Configuring Bridging and Data Link 
Switching Plus 


Most of the early protocols were designed without explicit network addresses. For that 
reason, the protocol does not have the same concept of traditional Layer 3 that we have 
grown to love. Protocols without explicit network layer addresses, by definition, are called 
nonroutable or bridged protocols. Some examples of common bridged protocols are |BM 
Systems Network Architecture (SNA), NetBEUI, NetBIOS, and DEC LAT. 


The most commonly used bridged protocols today are SNA and NetBEUI. IBM's SNA is found 
in many large data centers and is perhaps the most common bridged protocol that you will 
encounter in the field. With the advent of Windows 9x and Microsoft Networking, NetBEUI 
started to creep across many networks as well. 


Along with SNA, NetBEUI, and other nonroutable protocols comes the necessary evil of 
transporting them across multiple LAN segments and WAN segments. We call this a 
necessary evil because bridged traffic is extremely broadcast-intensive. Enabling bridging 
across your network can severely impact the performance of your network. For this reason, 
when you deploy any bridging on your network, try to control it or limit the segments of the 
network that it has to cross. 


This chapter focuses on ways to transport nonroutable protocols by using the following 
methods: 


Transparent bridging 

Integrated routing and bridging 
Source-route bridging (SRB) 

Remote source-route bridging (RSRB) 
Data link switching (DLSw) 
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Transparent Bridging 


Transparent bridging is used to transport nonroutable protocols across Ethernet networks. 
Transparent bridges first were developed by DEC in the early 1980s. DEC submitted the work 
to the IEEE, which incorporated it into the |EEE 802.1 standard. 


The basic function of a bridge is to forward data across the network. The bridge accepts 
frames, briefly examines them, and then makes a forwarding decision based on the 
information in that frame. The bridge accomplishes this by building a bridge or station table. 
Figure 13-1 illustrates the bridge table in a bridged network. 


Figure 13-1. A Bridged Network 
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Bridges operate at the first two layers of the OSI model. Recall from Chapter 2, "LAN 
Protocols: Configuring Catalyst Ethernet and Token Ring Switches," that the data link layer, 
Layer 2, is subdivided into two layers, the MAC and LLC. Bridges primarily operate at the MAC 
layer, working with source and destination MAC addresses. 


Transparent Bridging Operation 
Basically, a bridge operates in the following manner: 


1. When a transparent bridge initializes, it starts listening promiscuously to frames on the 
network. 


2. As frames are received on an interface, the source MAC address, along with the 
interface/port on which it was received, are recorded in a station cache or bridge table. 
The bridge table keeps track of all MAC addresses that the bridge is aware of and what 
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port they reside on. 


3. As subsequent frames are received, the bridge examines the frame for destination MAC 
addresses. The bridge then compares the address to the addresses in the bridge table 
or station cache and makes one of the following decisions: 


- If the MAC address resides on the network/interface where it was received, 
the bridge will not forward it and, subsequently, drops the frame. 


- If the MAC address is found in the bridge table, the bridge forwards the frame 
only onto the interface/port specified in the table. 


- If the bridge has no record of the MAC address, it floods the frame out all 
ports except the port that received the frame. 


4. The bridge ages each entry in the station cache and deletes it after a period of time, 
known as the MAX Age timer. The MAX Age timer flushes entries from the bridge table 
when no traffic is received with a source MAC address matching the MAC address 
stored in the bridge table. 


Spanning Tree Review 


Because bridges use the process of flooding frames from segment to segment, they need a 
way to control loops. Three types of loop- prevention mechanisms are available on Cisco 
routers: 


e IEEE 802.1d Spanning-Tree Protocol (STP). This is the same protocol discussed in 


detail in Chapter 2. 
e A digital protocol upon which this IEEE standard is based. 
e An1!BM form of STP used mainly for legacy transparent bridging on a Token Ring. 


All forms of STP are similar, so we will focus on the primary one in use and the one used as 
the default for Cisco switches—802.1d. 


The following information is reprinted from Chapter 2 that STP transitions through the phases 
illustrated by Figure 13-2 and explained in the sections that follow. 


Figure 13-2. The STP Transition 
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Disabled State 


This state appears when a bridge having problems processes Bridged Protocol Data Units 
(BPDUs), when a trunk is improperly configured, or when the port is administratively down. 


Listening State 


When a bridge port initializes, or in the absence of BPDUs for a certain amount of time, STP 
transitions to the listening state. When STP is in this state, the port is actually "blocking," and 
no user data is sent on the link. STP follows a four-step process for convergence: 


1. 


4. 


Elect one root bridge— Upon initialization, the bridge begins sending BPDUs on all 
bridged interfaces. A root bridge is chosen based on the bridge with the lowest bridge 
ID (BID). Recall that the BID is a combination of a priority and MAC address. In the 
event of a tie, the bridge with the lowest MAC address is chosen as root. All ports of 
the root bridge are put in forwarding state. 


Elect one root port for every nonroot bridge— When a single root bridge has been 
elected, STP elects a single root port on each bridge/switch that is not root. The root 
port is the bridge's/switch's best path to the root bridge. After a root port is elected, it 
is put into the forwarding state. To determine what port should be a root port, STP 
prioritizes based on criteria in the following order: 


- Lowest root BID 

- Lowest path cost to root bridge; the cumulative cost of the all paths to root 
- Lowest sender BID 

- Lowest port ID 


When a bridge receives a BPDU, it stores it in a bridge table for that port. As new 
BPDUs are received on that port, they are compared to existing BPDUs. Using the four- 
step process listed previously, BPDUs that are more attractive or that have lower costs, 
are kept, and the other ones are discarded. The primary variable that influences the 
root port election is the cost to the root bridge. The cost to the root bridge is the 
cumulative path cost of all links to root bridge. 


Elect one designated port/ designated bridge for every segment— For every 
segment, STP elects one port that will send and receive all information from that 
segment to the root bridge. A root port can be thought of as the port that forwards 
information to the root, whereas the designated port can be thought of as the port that 
sends traffic away from the root. This rule applies mostly to shared-media bridges, or 
routers. Designated ports on switched trunk lines do not follow this rule. 


All remaining ports will become nondesignated ports and are put in blocking 
mode. 


Learning State 


Ports that remain designated or root ports for a period of 15 seconds, the default forward 
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delay, enter the learning state. In the learning state, the bridge waits another 15 seconds 
while it builds its bridge table. 


Forwarding and Blocking States 


When the bridge reaches this phase, ports that do not serve a special purpose, such a root 
port or a designated port, are called nondesignated ports. All designated ports are put in 
forwarding state, while all nondesignated ports are put in a blocking state. In the blocking 
state, a bridge does not send any configuration BPDUs, but it still listens to them. A blocking 
port also does not forward any user data. 


STP Timers 


STP has three basic timers that regulate and age BPDUs: 


e Hello timer— The default hello timer is 2 seconds. This is the amount of time between 
configuration BPDUs sent by the root bridge. 


e Forward delay— This timer is the default 15 seconds that the router/bridge waits 
while building its bridging table. The listening and learning stages each use this single 
15-second timer. 


e MAX Age— This timer indicates how long a BPDU is stored before it is flushed. If this 
timer expires before the interface receives a new BPDU, the interface transitions to the 
listening state. An expired MAX Age parameter usually is caused by a link failure. The 
default value is 20 seconds. 


STP uses the hello timer to space BPDUs and has a keepalive mechanism. The hello timer 
always should prevent the MAX age value from being hit. When the MAX Age timer expires, it 
usually indicates a link failure. When this happens, the bridge re-enters the listening state. It 
takes approximately 50 seconds for STP to recover from a link failure; 20 seconds for the 
BPDU to age out, the MAX Age; 15 seconds for listening; and 15 seconds for the learning state. 


Configuring Transparent Bridging 


Configuring transparent bridging is a simple three-step process: 


Step 1. Assign a bridge group number and define the Spanning- Tree Protocol. This is 
accomplished with this global command: 


Router (config) # bridge-group [1-255] protocol [ieee | ibm | dec] 


Step 2. Assign each network interface that is to be bridged to a bridge group by using 
the following interface command: 


Router (config-if)# bridge-group [1-255] 


If the interface is a Frame Relay multipoint interface, a frame-relay map statement 
will be needed to map the bridge to a DLCI. The frame-relay map interface command 
is as follows: 
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Router (config-if)# frame-relay map bridge [DLCI Number_16-1007] 
broadcast 


If the interface is a DDR interfaces, such as an ISDN interface, a dialer-map statement 
will be needed to transport the bridged traffic across the DDR link. 


Router (config-if)# dialer map bridge [name {remote_host_name}] 
broadcast dialer_string 


Step 3. (Optional) Configure root for the Spanning Tree. Select which bridge or 
interface will serve as root. As mentioned previously, there are a couple of ways to 
influence root. The best and most direct way is to set the STP priority. STP priority can 
be set on the interface or global level, depending on how you want to influence root 
selection. The lower the priority, the more likely the bridge will become root. Use the 
following commands to influence STP root selection: 


To set the bridge priority, use the following global command: 


Router (config) # bridge-group [1-255] priority [0-65535] 


To set the bridge port priority, use the following interface command: 


Router (config-if)# bridge-group [1-255] priority [1-255] 


To set the bridge path cost, use the following interface command: 


Router (config-if)# bridge-group [1-255] path-cost [0-65535] 


The first step in setting up transparent bridging is to define a Spanning-Tree Protocol and 
assign it a bridge group number. You can choose either the [EEE 802.1D Spanning-Tree 
Protocol or the Digital or |BM versions. The IEEE 802.1D Spanning-Tree Protocol is the 
preferred way of running the bridge. Use the Digital Spanning-Tree Protocol or the IBM version 
only for backward compatibility. 


The next step is to assign each network interface to a bridge group. A bridge group is defined 
by Cisco as follows: 


An internal organization of network interfaces on a router. Bridge groups within 
the same router function as distinct bridges; that is, bridged traffic and bridge 
protocol data units (BPDUs) cannot be exchanged between different bridge 
groups on a router. Furthermore, bridge groups cannot be used to multiplex or 
demultiplex different streams of bridged traffic on a LAN. An interface can be a 
member of only one bridge group. 


If you are configuring bridging over a Frame Relay multipoint network or DDR network, an 
additional map statement will be needed to carry the bridged traffic over the network. 


A couple of reasons exist for placing the interface into a bridge group: 


e To bridge all nonroutable traffic among the network interfaces making up the bridge 
group. 
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e To participate in a common Spanning-Tree Algorithm by receiving and transmitting 
BPDUs on the LANs that are in the same bridge group. A separate spanning process 


runs for each configured bridge group. Each bridge group participates in a separate 
Spanning Tree. 


In Figure 13-3, interfaces eO and el are in bridge group 1. These interfaces will forward 


bridged traffic to another. Interface e3 is not part of the bridge group and will not receive 
traffic from the bridge group. 


Figure 13-3. Transparent Bridging Bridge Groups 
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An effective way to isolate bridged traffic on switched networks is to create a 
VLAN just for bridged traffic. Any devices that require bridged traffic will exist on 
this VLAN. Data-link switching then can be used to take this VLAN traffic or 
bridged traffic across the LAN or WAN, without propagating its traffic to every 
segment in between. 


Transparent Bridging Model 


Figure 13-4 presents a practical example of transparent bridging. In this model, the 
workstations are MS Windows 9x running NetBEUI, a nonroutable protocol. For the 
workstations to communicate, transparent bridging must be enabled across the Frame Relay 
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network and on the Ethernet interfaces of the routers shuttle_5 and shuttle_6. 


Figure 13-4. Transparent Bridging 
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To enable transparent bridging on the enterprise router, follow the three-step process. Begin 
by assigning a bridge group and STP to the bridging domain. This is accomplished with the 
global router command bridge group 1 protocol ieee. |n this model, you will be using 
802.1d as the Spanning-Tree Protocol. The second step involves assigning interfaces to bridge 
groups. This is done with the interface command bridge-group 1. On the enterprise router, 
this command must be entered on the EO interface, sO.1 and sO.2 Frame Relay interfaces. 
Because SO.1 is a Frame Relay multipoint, it also needs to have a frame-relay map bridge 
statement, mapping a specific DLCI to the bridge. Finally, the third step involves setting a root 
bridge. In this model, we have chosen the enterprise router to be the root for STP. To force 
root selection, we elected to use the global router command bridge-group 1 priority 100, 
setting the bridge priority of the enterprise router/bridge to be 100. Example 13-1 lists the 
configuration of the enterprise router. 


Example 13-1 Transparent Bridge Configuration on the enterprise 
Router 


hostname enterprise 

! 

<<<text omitted>>> 

! 

interface Ethernet2 

ip address 172.16.10.1 255.255.255.0 
no ip directed-broadcast 

media-type 10BaseT 
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‘bridge-group 1 = * Assign 2 to bridge 1 
! 

<<<text omitted>>> 

! 

interface Serial0 

no ip address 

no ip directed—-broadcast 
encapsulation frame-relay 

no ip mroute-cache 

logging event subif-link-status 
logging event dlci-status-change 
frame-relay lmi-type cisco 

! 

interface Serial0.1 multipoint 

ip address 172.16.1.1 255.255.255.0 
no ip directed—-broadcast 


frame-relay map ip 172.16.1.6 130 broadcast 


interface Serial0.2 point-to-point 
ip address 172.16.2.1 255.255.255.0 
no ip directed-broadcast 
frame-relay interface-dlci 102 


(bridge-group 20 sign $0.2 to bridge 1 
! 


<<<text omitted>>> 
! 


! 


The configurations of the shuttle_5 and shuttle_6 routers resemble the enterprise router's 
configuration. Example 13-2 lists the bridging portions of the shuttle_5 and shuttle_6 routers, 
respectively. Note that the Frame Relay map statements are needed only on Frame Relay 
multipoint networks. 


Example 13-2 Transparent Bridge Configuration on the shuttle_5 and 
shuttle_6 Routers 


hostname shuttle_5 
! 
interface Ethernet0O 
ip address 172.16.5.5 255.255.255.0 


! 

interface Serial0 

ip address 172.16.2.5 255.255.255.0 
encapsulation frame-relay 
frame-relay interface-dlci 121 
frame-relay lmi-type cisco 
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‘bridge-group 20 * Assign 80 to bridge 1 
! 


<<<text omitted>>> 
! 


bridge 1 protocol ieee = =“ Define bridge 1 with 802.1d as the STP 
: 


hostname shuttle_6 
'! 
interface Ethernet0O 
ip address 172.16.6.6 255.255.255.0 
no ip directed-broadcast 


! 


ip address 172.16.1.6 255.255.255.0 
no ip directed-broadcast 
encapsulation frame-relay 

no ip mroute-cache 

no fair-—queue 


frame-relay map ip 172.16.1.1 131 broadcast 


! 


<<<text omitted>>> 
! 


Verifying Transparent Bridging, the "Big show" for Transparent Bridging and 
STP 


Cisco offers some useful commands that aid in verifying the operation of the bridging 
environment. | can't recommend using any of the debug commands for transparent bridging. 
The ones available are cryptic or offer little valuable information—for example: 


11:23:34: ST: Serial0.1 0000000000800000605CF35DA400000000800000605CF35DA4800600 
00140002000F00 


Instead of trying to break down the bit stream that debug spantree tree provides, use other 
commands that prove to be more useful and easier to understand. The big show commands 
are as follows: 


show bridge [bridge_number] 
show spanning-tree [bridge_number] 


show bridge Command 


The show bridge command shows the current state of the bridge, the MAC addresses it has 
learned, and whether it is forwarding on specific interfaces. Age and transmit and receive 
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counts are also listed. If the bridge number is appended to the comman4d, it lists the known 
bridge ports and the STP state they are in: learning, listening, forwarding, or blocking. 
Example 13-3 demonstrates the versions of the show bridge command on the shuttle_5 
router from the previous model. For a more detailed explanation of the STP states, see 
Chapter 2. 


Example 13-3 show bridge Command Output on the shuttle_5 Router 


shuttle_5#show bridge 


Total of 300 station blocks, 296 free 
Codes: P - permanent, S - self 


Bridge Group 1: 


Address Action Interface Age RX count TX count 
0000.8139.6c45 forward Etherneto 0) 248 0 
0000.863c.3b41 forward Serialo 0 126 LOT 
00e0.b055.5789 forward Serialo 0 506 0) 
00a0.cc74.54a4 forward Etherneto 0) 449 157 


shuttle_5#show bridge group 
Bridge Group 1 is running the IEEE compatible Spanning Tree protocol 


Port 2 (Ethernet0O) of bridge group 1 is forwarding 
Port 6 (SerialO Frame Relay) of bridge group 1 is forwarding 


show spanning-tree Command 


The show spanning-tree command for bridges provides nearly identical information as the 
show spanning-tree command found on the Catalyst switches. The relevant information that 
this command provides is the current root of the Spanning Tree, the cost to root, its priority, 
as well as detailed STP timer information. For more specific information on the fields listed and 
their meaning, review the section, "Chapter 2. Example 13-4 lists the output of the show 
spanning-tree command on the enterprise router from the previous model. Note that this 
bridge is root and has a priority of 100, just as configured in the model. 


Example 13-4 show spanning-tree Command on the enterprise Router 


enterprise#show spanning-tree 
Bridge group 1 is executing the IEEE compatible Spanning Tree protocol 
Configured hello time 2, max age 20, forward delay 15 


Topology change flag not set, detected flag not set 
Times: hold 1, topology change 35, notification 2 

hello 2, max age 20, forward delay 15 
Timers: hello 0, topology change 0, notification 0 
bridge aging time 300 


Port 8 (Ethernet2) of Bridge group 1 is forwarding 
Port path cost 100, Port. priority 128 
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Designated root has priority 100, address 00e0.1e58.e798 
Designated bridge has priority 100, address 00e0.1e58.e798 
Designated port is 8, path cost 0 

Timers: message age 0, forward delay 0, hold 0 

BPDU: sent 876, received 0 


Port 13 (Serial0.1 Frame Relay) of Bridge group 1 is forwarding 
Port path cost 647, Port priority 128 
Designated root has priority 100, address 00e0.1e58.e798 
Designated bridge has priority 100, address 00e0.1e58.e798 
Designated port is 13, path cost 0 
Timers: message age 0, forward delay 0, hold 0 
BPDU: sent 632, received 2 


Port 14 (Serial0.2 Frame Relay) of Bridge group 1 is forwarding 
Port path cost 647, Port priority 128 
Designated root has priority 100, address 00e0.1e58.e798 
Designated bridge has priority 100, address 00e0.1e58.e798 
Designated port is 14, path cost 0 
Timers: message age 0, forward delay 0, hold 0 
BPDU: sent 347, received 0 


enterprise# 


NOTE 


Various levels of Cisco 1|OS Software Release 12.0 have Spanning Tree disabled 
by default. To enable Spanning Tree, use the command no bridge-group 
bridge_number spanning-disabled. 


Verifying Transparent Bridging with Windows 9x or 2000 


Windows 9x or 2000 with Microsoft networking enabled—or, more specifically, NetBEUI enabled 
—provides a great test application for all bridged and DLSw networks. To test any bridging 
type environments, use two Windows workstations with Microsoft networking and NetBEUI 
enabled. If you also enable Microsoft file and print sharing, you will be able to test file 
transfers across the bridged or DLSw network. Using the network browser or the Find 
Computer application in Windows, you can force broadcast data across the network. For more 
information on configuring Windows networking, see Chapter 1, "The Key Components for 


Modeling an Internetwork," or consult the Microsoft documentation. 
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Integrated Routing and Bridging 


Integrated routing and bridging (IRB) allows you to bridge local traffic within several 
segments while having hosts on the bridged segments reach the hosts or routers on routed 
networks. It essentially can allow a routed domain to reach a bridge domain. 


Using the IRB feature, you can route a given protocol between routed interfaces and bridge 
groups within a single router. Specifically, local or unroutable traffic will be bridged among 
the bridged interfaces in the same bridge group, while routable traffic will be routed to other 
routed interfaces or bridge groups. 


Integrated routing and bridging uses the concept of a Bridge-Group Virtual Interface (BVI) to 
enable these interfaces to exchange packets for a given protocol. A BVI is a virtual interface 
within the router that acts like a normal routed interface. A BVI does not support bridging, 
but it actually represents the corresponding bridge group to routed interfaces within the 
router. The interface number is the link between the BVI and the bridge group. All Layer 3 
information, such as IP address, or filters are applied to the BVI, not the actual physical 
interface. 


IRB Considerations 


Before enabling IRB, you should be aware of the following: 


e The default route/bridge behavior on a router is to route all packets first and then 
bridge them. This is precisely why configuring transparent bridging does not impact 
the routed domain. However, when the IRB is enabled, the behavior changes to bridge 
all packets first. The bridge group must be enabled to route with command bridge 
bridge_number route ip if routing IP also is enabled. 

e Packets of nonroutable protocols, such as local-area transport (LAT) or SNA, always 
are bridged. You cannot disable bridging for the nonroutable protocols. 

e Bridging attributes cannot be configured on a BVI interface. 

e |!RB supercedes concurrent routing and bridging (CRB), which no longer should be 
used. 


Figure 13-5 illustrates a common IRB environment. In this figure, note that there are no 
Layer 3 addresses on the Ethernet interfaces that are in the bridged domain. These interfaces 
are made part of the BVI by being members of the same bridge group. The BVI number—in 
this case, 10O—must be the bridge number. This number is how the two domains are linked. 
The BVI interface is where all layer information goes for the protocol that you want to bridge 
and route. In this figure, you simply have an IP address. By adding an IP address to the BVI 
interface, it instructs the router to start to bridge IP on all interfaces that are a member of 
bridge group 10. 


Figure 13-5. Integrated Routing and Bridging 
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interface e0 


interlace BVI 10 no ip address 
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hy si ip address 
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ip address 172.15.1.1/24 Bridged domain 


Routed domain 


interface a0 
ip address 172.15.1.2/24 


Configuring IRB 


Configuring IRB is a three-step process. The steps are as follows: 


Step 1. Configure transparent bridging on the interfaces that you want to bridge and 
route. Use the process defined earlier. Recall that this consists of creating a bridge 
group and assigning interfaces to that group. 


Step 2. Configure IRB and the BVI. Assign the same bridge number to the BVI 
interface. For example if you use bridge 2, the BVI will be interface bvi 2. To enable 
IRB, use the following syntax from the router global configuration prompt: 


Router (config)# bridge irb 
Router (config)# interface bvi bridge-group_number 


Step 3. Configure protocol-specific routing and bridging for the bridge group. This 
step is extremely important. As soon as you enable IRB with the bridge irb 
command, all interfaces in that bridge group, or all interfaces that have transparent 
bridging enabled on them, will now bridge all protocols first. This can and will have 
devastating effects where routing is needed for another protocol on those links. 
Because of this, all Layer 3 protocols must be told whether to route, bridge, or do 
both. To accomplish this, you must complete two steps: 


1. Assign all Layer 3 addresses of the protocol that you want to bridge and route 
to the BVI interface. No Layer 3 addresses should reside on the physical 
interface for the protocol that you want to bridge and route. 

2. Enable or disable routing and bridging on a per-protocol basis. 


To enable bridging or routing per protocol, use the following syntax from the yh 


configuration prompt: 


Router (config) # bridge bridge_number [route | bridge] [ip | ipx | 
appletalk | decnet] 


To disable bridging or routing per protocol, use the following syntax from the global 
configuration prompt: 


Router (config) # no bridge bridge_number [route | bridge] [ip | ipx | 
appletalk | decnet] 


To view whether the router is routing, bridging, or both for any given protocol, use the 
command show interface irb, as demonstrated in Example 13-5. 


Example 13-5 show interface irb Command Output 


irb_router#show int irb 


Ethernet2 


Software MAC address filter on Ethernet2 
Hash Len Address Matches Act Type 


OxV0t “OO LEEEL PEEL. EEEE 0 RCV Physical broadcast 
Ox2A: 0 0900.2b01.0001 0 RCV DEC spanning tree 
Ox86: O 00e0.1e58.e798 O RCV Interface MAC address 
OxCOs. 0 OL00L0GCEE. Gece GC RCV -CDP 

Oxc2: 0 0180:.c200..0000 O RCV IEEE spanning tree 
OxC2: 1. 00280:.c200:.:0000 0 RCV IBM spanning tree 


Practical Example: Configuring IRB 


Figure 13-6 shows a network where you want to bridge and route IP on interfaces e2 and e3. 
To configure IRB on this router, you begin by defining a bridge group and placing the 
interfaces that you want to bridge and route into that bridge group. In this example, we have 
made bridge group 5 and placed interfaces e2 and e3 into that bridge group. 


Figure 13-6. Integrated Routing and Bridging Example 
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IP bridge IPX only router 


interlace ee 
ip- 12.16.1124 


No BVI creater i interface 3 
No BV! created yet . bridge-group 5 ip-172.16.2.1/24 IP bridge 
. LT _ . IPx 20) : 
alae ) bridge-group 5 
~>, 
Inferface a4 Bridged domain 
ip address 172.16.3.1/24 bridge 5 
IP SO 


Routed domain 


interface eD 
ip address 172.16.3.2/24 


If you examine IRB, at this point, it looks much like a normal router. Example 13-6 lists the 
output of the show interface irb command on the irb_router. Notice that the router is either 
bridging or routing IP, but not both. 


Example 13-6 show interface irb Command Output 


irb_router#show int irb 


Ethernet2 

Bridged protocols on Ethernet2: 
appletalk clns decnet vines 
apollo xns 


Software MAC address filter on Ethernet2 
Hash Len Address Matches Act Type 


Ox00s O £ELL.£ETL. £LLE O RCV Physical broadcast 
Ox2A: 0 0900.2b01.0001 0 RCV DEC spanning tree 
Ox86: O 00e0.1e58.e798 O RCV Interface MAC address 
OxcCOs 0 0100..0cee. cece 0 REV CDP 

0x2: O 0080..6200..0 000 O RCV IEEE spanning tree 
Oxc2: 1. '0180.¢c200.0000 0 RCV IBM spanning tree 
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Ethernet3 
Bridged protocols on Ethernet3: 
appletalk clns decnet vines 


apollo xns 


Software MAC address filter on Ethernet3 
Hash Len Address Matches Act Type 


Ox00s WO LEER EERE. TEP E 0 RCV Physical broadcast 
Ox2A: 0 0900.2b01.0001 0 RCV DEC spanning tree 
0x85: 0O 00e0.1e58.e79b O RCV Interface MAC address 
OxCOs- “0 OL00 GCE. Gece 0 RCV CDP 
Oxc2: 0 01780.¢200.0000 O RCV IEEE spanning tree 
OxC2s L 0080'.c200...0000 0 RCV IBM spanning tree 
Ethernet4 
ROUSE dnO Ce eee eso Eee ee 


irb_router# 


The second step in the configuration involves enabling IRB and creating the BVI. Because you 
are using bridge 5, the BVI interface will be 5, too. When the BVI is created, the router 
generates the statements needed to route whatever Layer 3 protocol it discovers on a 
transparently bridged interface. Example 13-7 shows this happening when IRB was enabled in 
the model. In this model, IPX and IP are enabled on a transparently bridged interface, so 
both commands were generated. 


Example 13-7 Enabling IRB 


irb_router (config) #bridge irb 

IRB: generating ‘bridge 5 route ip' configuration command 

IRB: generating "bridge 5 route novell' configuration command 

irb_router (config) #int bvi 5 

04:17:56: SLINEPROTO-5—-UPDOWN: Line protocol on Interface BVI5, changed state to 
up 

irb_router (config-if) # 


Now you want to remove the Layer 3 address of the protocol that we want to route and 
bridge from the physical interface. All other Layer 3 addresses, the ones that you do not want 
to bridge and route on, should remain on the physical interface. Assign the Layer 3 address of 
the protocol to bridge and route to the BVI interface. Figure 13-7 illustrates the changes that 


you need to make to the network. 


Figure 13-7. Addressing and Creating the BVI 


848 


IP bridge 


CPF IPX only router 


interface BVI 5 se irianeras 
ip - 172.716.1124 sala Oe IP bridge 
no ipx network ~, no ip address 


IPX 20 
bridge-group 5 


interface a4 fe 


ip-172.16.3.1/24 
IPX 30 


Bridged domain 
bridge 5 


Routed domain 


interface eo 
ip address 172.16.3.2/24 


After the IP address changes have been made, the model is almost complete. At this point, IP 


is being bridged and routed, and this can be verified with the show int irb command, as in 
Example 13-8. 


Example 13-8 show interface irb Command Output 


irb_router#show int irb 


BVI5 


Ethernet2 


Software MAC address filter on Ethernet2 


Hash Len Address Matches Act Type 
Ox00s: 0 £LELLLELEL. fret 0 RCV Physical broadcast 
Ox2A: 0 0900.2b01.0001 0 RCV DEC spanning tree 


849 


0x86 O 00e0.1e58.e798 O RCV Interface MAC address 

0x86 1 00e0.1e58.e798 O RCV Bridge-group Virtual Interface 
OxCO 0 0L00'..0dee.ccec 0 RCV CDP 

OxC2Z 0 0180.¢200.0000 O RCV IEEE spanning tree 

OREZ 1 0180:.e€200../00:00 0 RCV IBM spanning tree 


Software MAC address filter on Ethernet3 
Hash Len Address Matches Act Type 


0x00 OC. tiresrrit, frre 0 RCV Physical broadcast 
Ox2A 0. G900.2b501.. 0001 O RCV DEC spanning tree 
0x85 0 00e0.1e58.e79b O RCV Interface MAC address 
0x86 0 00e0.1e58.e798 O RCV Bridge-group Virtual Interface 
OxCO 0 OLOO.00Gee. cece 0 RCV CDP 
OxC2 0 0180.c200.0000 0 RCV IEEE spanning tree 
OxREZ 1, OL80%.6200:. 0000 0 RCV IBM spanning tree 
Ethernet4 
cll lon es ogee oils ariel 
i EE a sc 


irb_router# 


By observing the output of Example 13-8, you can see that the BVI appears as a normal 


interface, much like interface E4. Notice that only IP is running on the BVI because that is the 
only protocol that you want to bridge and route. 


Notice in this model that you have a downstream | PX router. All |PX traffic first is bridged, 
and this causes problems with the downstream |IPX router. To remedy this, the second part of 
Step 3 calls for you to disable IPX bridging with the command no bridge 5 bridge ipx. After 
keying in this command, you can view the IRB interface and note the changes. IPX no longer 
is bridged and routed on the interfaces E2 and E3; it is only routed. Example 13-9 lists the 


output of the show irb command, illustrating that |PX no longer is bridged and routed. 


Example 13-9 show interface irb Command Output 


irb_router#show int irb 
BVI5 


Routed protocols on BVIS5: 


1p 
Ethernet2 
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Software MAC address filter on Ethernet2 
Hash Len Address Matches Act Type 


Ox00s O LEE. EERE ELE 0 RCV Physical broadcast 

Ox2A 0 0900.2b01.0001 0 RCV DEC spanning tree 

0x86 0 00e0.1e58.e798 O RCV Interface MAC address 

0x86 1 00e0.1e58.e798 O RCV Bridge-group Virtual Interface 
OxCO 0 CLOG .0cec.cece 0: RCV ‘CDP 

OxREZ 0 0180.c200.0000 0 RCV IEEE spanning tree 

OxC2 1 0180.c200.0000 0 RCV IBM spanning tree 


Hash Len Address Matches Act Type 
0x00 O £ELE  FEEE. EEL E 0 RCV Physical broadcast 
Ox2A 0 0900.2b01.0001 O RCV DEC spanning tree 
0x85 0 00e0.1e58.e79b O RCV Interface MAC address 
Ox86: 0 00e0.1e58.e798 O RCV Bridge-group Virtual Interface 
OxCO 0: C1LO0..0cce. cece QO RCV CDP 
OREZ 0: OL80).e200%/00:010 O RCV IEEE spanning tree 
OxC2 1 0180.c200.0000 0 RCV IBM spanning tree 
Ethernet4 
Rep ES ae or ore See 
ie aes 


irb_router# 


Example 13-10 lists the configuration that we created for this model. 


Example 13-10 | RB Configuration for This Model 


hostname irb_router 

! 

ip subnet-—zero 

ipx routing 00e0.1e58.e792 
! 


bridge irb 
! 


<<<text omitted>>> 

! 

interface Ethernet2 

no ip address 

no ip directed-broadcast 
media-type 10BaseT 

ipx network 10 
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bridge-group 5 
! 
interface Ethernet3 
no ip address 
no ip directed-—broadcast 
media-type 10BaseT 
ipx network 20 
bridge-group 5 
! 
interface Ethernet4 
ip address 172.16.3.1 255.255.255.0 
no ip directed-broadcast 
media-type 10BaseT 
ipx network 30 
! 
<<<text omitted>>> 
! 
interface BVI5 
ip address 172.16.1.1 255.255.255.0 
no ip directed-broadcast 
! 
router eigrp 2001 
network 172.16.0.0 
! 
ip classless 
! 
bridge 5 protocol ieee 
bridge 5 route ip 
bridge 5 route ipx 
no bridge 5 bridge ipx 
! 
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Source Route Bridging (SRB) 


At the same time that the IEEE 802.1 committee was considering adapting transparent bridging 
for the standard to connect LANs, it also was reviewing source-route bridging as an alternative. As 
history tells us, the IEEE 802.1 committee adopted transparent bridging. When this happened, 
source-route bridging was presented before the IEEE 802.5, where it found a home as the 
protocol to connect IBM Token Ring LANs and IEEE 802.5 LANs. Figure 13-8 represents the 802.5 
Token Ring frame. 


Figure 13-8. |EEE 802.5 Token Ring Frame Format 
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Fi 
Field = 


Source-Route Bridging Overview 


Source-route bridging uses a combination of explorer packets and a RIF field to determine the 
best path through the bridged network. A source-route bridge uses the routing information field 
(RIF) in the [EEE 802.5 MAC header of a datagram, as in Figure 13-9, to determine which rings or 
Token Ring network segments the packet must transit. This is where the "route" in source route 
comes from. 


Figure 13-9. lLEEE 802.5 MAC Frame Format 


Destination Source Address DATA FCS 
Address 


The RIF is inserted into the MAC header immediately following the source address field in every 
frame by the source station. The destination station reverses the routing field to reach the 
originating station. Unlike transparent Spanning Tree bridging that requires time—50 seconds to 
converge in the event of failures—source-route bridging allows multiple active paths through the 
network, which provides an extremely efficient way to use alternate paths in the event of a 
failure. Most importantly, source-route bridging places the burden of transmitting frames on the 
end stations by allowing them to determine the best routes for frames across the network. The 
IBM Token Ring specifies a maximum number of 8 rings and 7 bridges in the RIF, while 802.5 
specifies a maximum of 14 rings and 13 bridges. Figure 13-9 represents the 802.5 MAC Frame. 


The ring in a Token Ring network is designated in the routing information identifier (RII) by a 
unique 12-bit ring number ranging from 1 to 4095. Each bridge between two Token Rings is 
designated by a unique 4-bit bridge number in the RIF. The valid bridge numbers are 1 to 15. 
Bridge numbers must be unique only between bridges that connect the same two Token Rings. If 
the RII is set to 0, there will be no RIF in the frame; if the RII is set to 1, a RIF will be included in 
the frame. 


The RIF Field 


The RIF is composed of 16-bit routing control fields and routing descriptor fields. Figure 13-10 
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illustrates the basic RIF format. 


Figure 13-10. Basic RIF Format 


RC oe 


RC = Routing Control field 
RD = Routing Descriptor 
Each block is 16 bits wide. 


Figure 13-11 illustrates the routing control format for the RIF, followed by the descriptions of each 
field. 


Figure 13-11. RIF Routing Control Format 


e Shaded fields are reserved. 
e type— The explorer type is used, as follows: 


- 00: Specific routes explorer 
- 10: All rings, all-routes explorer 
- 11: All rings, spanning routes (limited broadcast) 


e length— This is the total length in bytes of the RIF. 
e D-— This is the direction, indicated as follows: 


- O: Interpret route left to right (forward) 
- 1: Interpret route right to left (reverse) 


e largest— This is the largest frame that can be handled by this route, as follows: 


- 000: 516 bytes (DDN 1822) 
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- 001: 1500 bytes (Ethernet) 

- 010: 2052 bytes 

- O11: 4472 bytes (Token Ring and Cisco maximum) 
- 100: 8144 bytes (Token Bus) 

- 101: 11,407 bytes 

- 110: 17,800 bytes 

- 111: 65,535 (initial values) 


Figure 13-12 describes the routing descriptor format of the RIF string. When you configure a 
static RIF or when a RIF is represented, it is represented in dotted hexadecimal. 


Figure 13-12. Routing Descriptor Format 


8 


Ring Number Bridge Number 


e Ring number— Unique decimal ring number within the bridged network. 


e Bridge number— Unique decimal bridge number between any bridges connecting the 
same two rings. A bridge number of 0 indicates that the RIF is terminating. 


Figure 13-13 shows an SRB network. The RIF from station Alpha to station Bravo would read as 
follows: 


0830.0012.002a.00b0 


Figure 13-13. Source-Route Bridge—RI F 


RIF = 0830.0012.002a.00b0 
or 
RING1-BRIDGE2-RING2- 
BRIDGE10-RING11 


r eal P val 


Station Alpha Stallon Bravo 
MAC-4000.1000.1000 MAC~43000.1000.2000 


The 0830 is the 16-bit RC field, and 0012, 002a, and 00b0 are the three 16-bit RD fields. The first 
four bits, from left to right, state that the explorer type is 0, or a specific routes explorer. The 8 
says that the entire RIF is 8 bytes in length. The D bit is set to 0, indicating that the RIF is read 
from left to right, or forward. The next three bits are set to 011, which sets the frame size to be 
4472, the Cisco maximum. The RD fields break down rather easily: 
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RING1-BRIDGE2 = 0012 
RING2-BRIDGE10 = 002a 
RING11-BRIDGEO = 00b0 


A bridge of 0 tells the SRB to terminate the RIF and that no more bridges follow the ring. For 
more information on configuring a static RIF, see the section entitled "Configuring a Static RIF." 


A source-route bridge can determine whether to forward an explorer into a ring by looking at the 
RIF field. An explorer packet will not be forwarded to a ring where a duplicate ring-bridge- ring 
pattern already exists in the RIF. 


The information in a RIF is derived from explorer frames generated by the source node. These 
explorer packets traverse the entire source-route bridge network, gathering information on the 
possible paths the source node might use to forward traffic. SRBs use three types of explorer 
frames: 


e All-routes explorer or all-rings explorer— This type of explorer is propagated from 
ring to ring from each SRB toward its destination. The destination station receives an all- 
routes explorer and forwards a directed, nonbroadcast frame back at the source that 
originated it. 


e Specific routes explorer or local explorer— This type of explorer is used by the end 
station to locate a specific station on a local ring. NetBIOS and SNA produce these types of 
explorers. 


e Spanning explorer or limited routes explorer— Spanning explorer can be propagated 
only if the Token Ring interface has source-bridge spanning enabled. Protocols such as 
NetBIOS require this type of explorer frame. When an end station receives a spanning 
explorer, it responds with an all-routes explorer frame sent toward the originating station. 


Figures 13-14 and 13-15 illustrate how the all-routes explorers and spanning explorers operate. 


Figure 13-14. SRB All-Routes Explorer 
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Figure 13-15. SRB Spanning Explorer 
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Configuring Source-Route Bridging 


Source-route bridging can be configured in three primary ways: 


e Basic local SRB 
e Multiport local SRB 
e Remote source-route bridging (RSRB) 


Configuring Basic Local Source-Route Bridging 


Local SRB in its simplest form exists between two rings on a router. Figure 13-16 illustrates this 
type of configuration. 


Figure 13-16. Basic Local SRB Configuration 


Station Alpha 
To configure this type of SRB, follow this two-step process: 


Step 1. Enable the use of the RIF, if required, with the router interface command 
multiring all. The full syntax is as follows: 


Router (config-if) #multiring {protocol-keyword | all other} 
no multiring {protocol-keyword | all | other} 


The Cisco |OS Software allows you to also specify a protocol. This is specified by the 
argument protocol-keyword. This keyword allows for per-protocol specification of the 
interface's capability to append RIFs to routed protocols. When it is enabled for a protocol, 
the router will source packets that include information used by source-route bridges. The 
protocols supported and the keywords are as follows: 


apollo— Apollo Domain 


appletalk— AppleTalk Phases 1 and 2 857 


clns— ISO CLNS 

decnet— DECnet Phase IV 
ip— IP 

novell— Novell | PX 
vines— Banyan VINES 
xns— XNS 


Two other keywords are used with the multiring command. The keyword all enables the 
RIF for all frames, and this is the recommend use. The keyword other enables the RIF for 
any routed frame not included in the previous list of supported protocols. The no 
multiring subcommand with the appropriate keyword disables the use of RIF information 
for the protocol specified. 


Step 2. Configure SRB for the Token Ring interface. This is accomplished with the 
following interface command: 


Router (config-if) #source-bridge local_ring bridge_number 
destination_ring 


The configuration for SRB is shown in Example 13-11. 


Example 13-11 Local SRB Configuration 


interface TokenRing0O 

no ip address 

no ip directed-broadcast 
ring-speed 16 


Ree *~ RIF enabled 

ellie Le De| Prom ring 1 thru bridge 1 to ring 2 
! 

interface TokenRingl 

no ip address 

no ip directed-broadcast 

ring-speed 16 

Sreelsee *~ RIF enabled 

BerCeSetege series From ring 2 thru bridge 1 to ring 1 


Configuring Multiport Local Source-Route Bridging 


The other type of SRB is needed when there are more than two Token Ring interfaces to bridge 
between. This type of configuration requires a virtual ring to be defined on the router. A virtual 
ring is just as the name describes, a virtual entity that connects two or more physical rings locally 
or remotely. A virtual ring also is referred to as a ring group. As you will see in the next section, 
"Configuring Remote Source-Route Bridging," a virtual ring can span an entire |P domain. For 
now, the virtual ring will be limited to the local router. Figure 13-17 contains an example of a 
three-port SRB. To configure SRB between rings 1, 2, and 10, you will need to configure a virtual 
ring. Then, you will source- bridge every real Token Ring to the virtual ring. Figure 13-18 
illustrates conceptually how the network will look with the location of the virtual ring. 

858 


Figure 13-17. SRB Multiport Bridging 
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Figure 13-18. SRB Multiport Bridging Conceptual View 
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To configure this type of SRB, follow this four-step process: 


Step 1. Define a virtual ring on the router. This is accomplished with this global router 
command: 


Router (config) #source-bridge ring-group virtual_ring_number 
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The virtual ring number can range from 1 to 4095. 


Step 2. Enable the use of the RIF, if required, with the router interface command 
multiring all. The full syntax is as follows: 


Router (config-if) #multiring {protocol-—keyword | all other} 
no multiring {protocol-keyword | all | other} 


Step 3. Configure SRB for the Token Ring interface. This is accomplished with the 
following interface command: 


Router (config-if) #source-bridge local_ring bridge_number virtual_ring 


Step 4. (Optional) Enable Spanning Tree explorers. By doing so, you can reduce the 
number of explorers that transverse the network. NetBIOS and NetBEUI require Spanning 
Tree explorers to function properly. Cisco recommends enabling Spanning Tree explorers 
in complex multiprotocol networks. To enable them, use this interface command: 


Router (config-if) #source-bridge spanning 


Example 13-12 shows the configuration for local multiport SRB for the network in Figure 13-17. 


Example 13-12 Multiport SRB Configuration 


! 
interface TokenRing0O 

no ip address 

no ip directed-broadcast 
ring-speed 16 


eae Ma ‘~ RIF enabled 
! 


interface TokenRingl 

no ip address 

no ip directed-broadcast 
ring-speed 16 


PeteceeDeree saan “From ring 2 thru bridge 2 to V-ring 100 
! 


interface TokenRing2 

no ip address 

no ip directed-broadcast 
ring-speed 16 


pe Ei “RIF enabled 


Configuring Remote Source-Route Bridging 
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SRB also can be configured to span a single WAN serial interface or an entire |P domain. This type 
of configuration is called remote source-route bridging (RSRB), which involves defining a virtual 
ring to link the remote bridges. Figure 13-19 illustrates a Token Ring SRB network connected by a 
common Frame Relay network. 


Figure 13-19. RSRB Network Connected by a Frame Relay Network 
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To configure RSRB, you need to define a common virtual ring to connect all the SRBs. The most 
logical spot for the virtual ring is the IP network, or the WAN, in this example. Figure 13-20 
illustrates the RSRB with the virtual ring defined. 


Figure 13-20. RSRB Network with Virtual Ring Defined 
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RSRB offers a variety of options to encapsulate SRB information over the |P network. The options 
depend primarily on the WAN interface. RSRB can be configured with four types of encapsulation: 
direct, FST, TCP, and Frame Relay. All four types of configurations are similar, but some require 
additional configuration. Table 13-1 presents an overview of the four encapsulation types, 


described in greater detail in the list following the table. 


Table 13-1. RSRB Encapsulation Types and Requirements 


Encapsulation 
Type Link Type Required Syntax 


LAN—single hop only source-bridge remote-peer 
V_ring interface interface _ name 


WAN must use HDLC only 


Frame Relay WAN—Frame Relay source-bridge remote-peer V_ring 
only frame-relay interface interface_name 


frame-relay map rsrb dici_number 
TCP WAN or LAN source-bridge remote-peer 
V_ring tcp ip address 
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WAN or LAN source-bridge fst-peername ip_address 


source-bridge remote-peer V_ring fst 
ip_ address 


b V_ring = the virtual ring 


e Direct— Direct encapsulation is a quick way to encapsulate SRB frames over a single 
physical network between two routers. This command does not offer some of the 
advanced features of RSRB, such as local acknowledgment, but it is efficient. If direct 
encapsulation is used on a WAN interface, it must run HDLC as the data link protocol. 
Remember, direct encapsulation can be used only between two routers that are adjacent 
to each other. 


e Frame Relay— Frame Relay encapsulation uses RFC 1490 to directly encapsulate RSRB in 
the Frame Relay frame. Frame Relay encapsulation allows you to control RSRB on a per- 
PVC basis. In addition to the RSRB commands, a frame-relay map rsrb command is 
needed to map the rsrb to a DLCI number on multipoint interfaces. This type of 
encapsulation provides less overhead than TCP, but it does not offer some of the advanced 
features of TCP. 


e TCP— The TCP type of encapsulation provides the greatest benefits, but at a lower 
performance. Cisco recommends using this encapsulation when connecting Token Ring 
bridges across heterogeneous networks. TCP also provides load balancing and local 
acknowledgment. 


e FST— FST stands for Fast-Sequenced Transport. Although it consumes less overhead than 
TCP, it still is not as fast as direct encapsulation. FST can be used to connect more than 
one SRB, but it does not offer local acknowledgment. An FST RSRB also needs to have an 
FST peer name assigned. 


To configure RSRB, follow this four-step process: 


Step 1. Enable the use of the RIF, if required, with the router interface command 
multiring all. 


Step 2. Enable the virtual ring with the source-bridge ring-group virtual_ ring command. 
Step 3. Configure SRB from the physical ring to the virtual ring. 
Step 4. Determine the encapsulation type to use, and configure RSRB. 


Direct encapsulation: Create a remote peer for each peer router and one for the 
local router. Use the following global router command: 


- Router(config)#source-bridge remote-peer virtual_ring interface 
interface_name 

Frame Relay encapsulation: Create a remote peer for each peer router and one 
for the local router. Use the following global router command: 


Router (config) #source-—bridge remote-peer virtual_ring frame-relay 
interface 
interface_name dlci_number [lf largest_frame_size] 


- You also must add a frame-relay map statement for multipoint interfaces; use 
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the following interface command: 


Router (config-if) #frame-relay map rsrb dici_number 


TCP encapsulation: Create a remote peer for each peer router and one for the 
local router. Use the following global router command: 


Router (config) #source-—bridge remote-peer virtual_ring tcp ip_address 
[lf largest_frame_size] [local-ack] 


The IP address is the IP address of the remote router that you want to reach. You 
also must have IP connectivity to this address. 


FST encapsulation: First, create a source-bridge FST peer name. This peer should 
be a loopback address or a local Token Ring interface. Use the following global 


command: 


Router (config) #source-bridge fst-peername local_ip address 


- Next, create a remote peer for each peer router and one for the local router. Use 


the following global router command: 


Router (config) #source-bridge remote-peer virtual_ring fst ip_address 


[lf largest_frame_size] 


The IP address is the IP address of the remote router that you want to reach. You 


also must have IP connectivity to this address. 


NOTE 


We highly recommend using loopback addresses for the RSRB peers and DLSw 
peers. By pointing the peer to a loopback interface, you provide the peer with an 
interface that can be down only if the router is down or there is a problem with IP 
routing. A physical interface can go down, which will cause the peer to drop. This, in 
turn, could affect other interfaces on the remote router that might need to see the 
RSRB or DLSW traffic. By pointing the peer at a loopback interface, the peer will 
always remain up, thereby servicing all ports on the router independently of each 
other. 


Determining Source-Route Bridge Status 


You can view the status of the SRB by using the following commands: 


show source-—bridge 
show source-bridge interface 


The show source-bridge command displays information about all the SRBs on the router. With 
this command, you should verify the entries that you made to configure SRB with the output. 
Ensure that ring and bridge numbers match what you configured. If other bridges are active, you 
will see receive and transmit counts increment. This command also displays the number and type 
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of explorers received on the network. The command also display errors and drops on the SRB. For 
more detailed information about this and all source-route bridging commands, read the Cisco 
Press title Cisco 1|OS Bridging and IBM Networks Solutions. Example 13-13 lists the output of the 


show source-bridge command. 


Example 13-13 Status of the SRB 


srb_router#show source—-bridge 


Local Interfaces: receive transmit 

srn bn trn rps n max hops ent ent drops 
ToO i 4 100% b 7.7 @ 7297 2 154 
Tol 2 1 1 b 7 GE Ay 2 390 0 


Global RSRB Parameters: 
TCP Queue Length maximum: 100 


te 


No TCP peername set, TCP transport disabled 
Maximum output TCP queue length, per peer: 100 


Rings: 
bag Lt ome. local ma: 4007.781la.e789 TokenRingO fwd: 0 
Explorerss: =—===== Ge GUL PUL. ==saa=5 
spanning all-rings cotal spanning all-rings total 
To0 0 6856 6856 0 1 i 
Tod 0 1 i 0 390 390 


Explorer fastswitching enabled 


Local switched: 6300 flushed 0 max Bps 38400 
rings inputs bursts throttles output drops 
ToO 6300 0 0 0 
Tol 0 0 0 0 


srb_router# 


The show source-bridge interface command displays a quick overview of the SRB on the 
network. It displays the state, ring, and bridge number, as well as packets in and out. Use this 
command for a quick view on whether the bridge is operating and passing data. Example 13-14 
lists the output of this command. 


Example 13-14 Status of the SRB Interfaces 


srb srb_router#show source-bridge interfaces 


Vp sin x Packets 
Interface St MAC-—Address srn bn trn r x p bc IP-Address In Out 
ToO up 0007.781a.e789 i i 100 * b F 35373. 7393 
Tol up 0007.781a.e729 2 1 il b F 30158: “7228 


srb_router# 


Practical Example: Configuring Remote Source-Route Bridging 


Figure 13-21 models three Token Ring routers connected by a Frame Relay network. To couleurs 


RSRB on this network, you can follow the four-step process defined earlier. The first step is to 
enable the RIF field with the multiring all interface command. You will perform this on all the 
routers in the model. Second, you need to define a virtual ring. The logical location for the virtual 
ring in this model is the Frame Relay cloud. Therefore, you will make virtual ring 100 reside over 
the Frame Relay cloud. To configure the virtual ring 100, use the global router command source- 
bring ring-group 100. 


Figure 13-21. RSRB with TCP 


Tod) (P72, 16.10, 14. 
LEO: 17216028, 90, 


Tet IP 172.16. 3.524 
LBSO = 1216. 128.890, 


ToO IP17216.1.1/04 
LB20 - 17246.128 1/30. . Virtual 


2 Vie. 16,1,16 
NetBEW = 
Bones. 


The third step involves configuring SRB on all the routers that you want to connect through the 
RSRB. Example 13-15 lists the SRB configuration of the shuttle_15 and shuttle 3 routers. 


Example 13-15 SRB Configuration of shuttle_15 and shuttle_3 Routers 


hostname shuttle_15 

! 

<<<text omitted>>> 

! 

interface TokenRing0O 

ip address 172.16.1.1 255.255.255.0 
no ip directed-broadcast 

no ip route-cache 

no ip mroute-cache 

ring-speed 16 


multiring all == “RIF enabled 
"source-bridge 15 10 100° SRB from ring 15 through bridge 10 to V-Ring 100 


_source-bridge spanning = = “Enable support for NETBios and NetBEUI 
! 


hostname shuttle_3 

! 

interface TokenRing0O 

ip address 172.16.3.3 255.255.255.0 
ring-speed 16 


a =e 

“source-bridge 3.3100 ==)“ SRB from ring 3 through bridge 3 to V-Ring 100 
_source-bridge spanning = = “Enable support for NETBios and NetBEUI 

! 


— 


NOTE 
Using Windows 9x NetBEUI to Test RSRB 


In this model, you can test the bridge with Windows 9x networking, or, specifically, 
NetBEUI. Without actual traffic, the RSRB will stay in a closed state. When the RSRB 
detects traffic, the bridge will transition from a closed state to an open state. In a lab 
environment, you can generate the traffic needed for the RSRB with Windows 9x 
configured using NetBEUI for file and print sharing. In a Windows 9x configuration, 
when the network neighborhood is browsed (or select Start, Find, Find Computer), 
this forces traffic across the RSRB. When the RSRB detects traffic, the state of the 
RSRB transitions from closed to up. This is an effective and easy way to test the 
RSRB. Use this same testing technique to test your DLSw configurations. With two 
workstations configured, you can print and share files over transparent, source- 
route, or DLSw networks. Windows 2000, Me, and NT also can be used for testing. 


In this model, you will be testing the RSRB with Windows 9x networking. Therefore, you also will 
need to configure Spanning Tree explorers on the source-route bridge, as noted in Example 13-15. 


The final step is to select an encapsulation to use on the RSRB and to configure it. In this model, 
we are using TCP and the RSRB encapsulation. Each router in the RSRB group will be configured 
with three source-bridge remote-peer statements. One peer statement is needed for each 
peer, and one peer statement is needed for the local router. In this model, we deployed the use of 
loopback interfaces to connect the RSRB. Example 13-16 shows the full RSRB configuration for 
the enterprise router. Example 13-17 shows the RSRB portions of the configuration of the 


shuttle_15 router. 


Example 13-16 RSRB Configuration of the enterprise Router 


hostname enterprise 
! 


source-bridge ring-group 100 

source-bridge remote-peer 100 tep 172.16.128.10 ‘Peer for the local router 
source-bridge remote-peer 100 tep 172.16.128.5  *~ Peer for the shuttle_5 router 
source-bridge remote-peer 100 tep 172.16.128.1  *~ Peer for the shuttle_15 router 
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! 

! 

interface Loopback20 

ip address 172.16.128.10 255.255.255.252 
no ip directed—broadcast 

! 

interface Serial0d 

no ip address 

no ip directed—-broadcast 
encapsulation frame-relay 

no ip mroute-cache 

logging event subif—-link-status 
logging event dlci-status-—change 
frame-relay lmi-type cisco 

! 

interface Serial0O.1 multipoint 

ip address 172.16.2.5 255.255.255.252 
no ip directed—-broadcast 

frame-relay map ip 172.16.2.6 170 broadcast 
! 

interface Serial0.2 point-to-point 

ip address 172.16.2.1 255.255.255.252 
no ip directed—broadcast 

frame-relay interface-dlci 180 

! 

<<<text omitted>>> 

! 

interface TokenRingO 

ip address 172.16.10.1 255.255.255.0 
no ip directed-broadcast 

ring-speed 16 

multiring all 

source-bridge 1 1 100 

source-bridge spanning 

! 
router eigrp 2001 

network 172.16.0.0 

no auto-summary 


Example 13-17 RSRB Configuration of the shuttle_ 15 Router 


hostname shuttle_15 
! 


source-bridge ring-group 100 

source-bridge remote-peer 100 tep 172.16.128.1 ‘Peer for the local router 
source-bridge remote-peer 100 tep 172.16.128.5 | “Peer for the shuttle_S router 
source-bridge remote-peer 100 tep 172.16.128.10  ‘~ Peer for the enterprise router 
! 


interface Loopback20 

ip address 172.16.128.1 255.255.255.252 
no ip directed-broadcast 

! 

interface Serial0O 

ip address 172.16.2.6 255.255.255.252 
no ip directed-broadcast 

encapsulation frame-relay 

no ip route-cache 
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no ip mroute-cache 

logging event subif-link-status 
logging event dlci-status-change 
frame-relay map ip 172.16.2.5 171 broadcast 
! 

<<<text omitted>>> 

! 

interface TokenRingO 

ip address 172.16.1.1 255.255.255.0 
no ip directed-—broadcast 

no ip route-cache 

no ip mroute-cache 

ring-speed 16 

multiring all 

source-bridge 15 10 100 
source-bridge spanning 

! 

router eigrp 2001 

network 172.16.0.0 

no auto-summary 


The RSRB configuration can be verified in the same manner as a normal source-route bridge can. 
Using the show source-bridge command, verify that the TCP peers are in a closed or open 
state. The bridge will not transition from closed to open without some type of data sent across it. 
In this model, the workstation Bones browses the network neighborhood, thereby activating the 
RSRB. Example 13-18 shows the output of the show source-bridge command performed on the 


enterprise router. 


Example 13-18 show source-bridge Command Output 


enterprise#show source-bridge 


Local Interfaces: receive transmit 
srn bn trn rps n max hops ent ent drops 
ToO dt 1 LOO * df 7 TF 7 1019 0 0 


Global RSRB Parameters: 
TCP Queue Length maximum: 100 


Ring Group 100: 
This: TEP peers. 172.16.128.10 
Maximum output TCP queue length, per peer: 100 


Peers: state bg lv pkts_rx pkts_tx expl_gn drops TCP 
ECP) 17 25.16...123)5 10 = 3 ) 0 0 0 0 
TCR L924 16012355 open 3 0 1258 1019 ) ©) 
TEP L72.16.128. 2 open 3 ) 708 1019 346 0 

Rings: 

Rings: 
pne 3 Ent 3 remote ma: 4000.30b1.270a TCP 172.16.128.5 fwd: 0 
bre 10 mnie 15 remote ma: 4000.309a.68bb TCP 172.16.128.1 fwd: 0 

Explorers: —----—— Pnput === 0 euLpPUL SSH == 
spanning all-rings total spanning all-rings total 
To0 284 J25 1.019 0 ) 0 


Explorer fastswitching enabled 
Local switched: 1019 flushed 0 max Bps 38400 


rings inputs bursts throttles output drops 
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To0 L019 0 0 0 


enterprise# 


Now, modify the previous example to use Frame Relay as the encapsulation type of the RSRB. 
Figure 13-22 highlights the relevant portions of the network, listing the DLCls in use. 


Figure 13-22. RSRB with Frame Relay 
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To configure RSRB to use Frame Relay encapsulation, follow Steps 1 to 3, which are identical to 
those in the previous section. Frame Relay encapsulation requires only one source-bridge 
source-bridgeremote-peer statement for each remote router connecting the RSRB. In this type 
of RSRB, you do not configure a remote-peer statement for the local router. Instead, you need to 
add a Frame-relay map statement for RSRB on the multipoint subinterface. Example 13-19 lists 
the configuration of the enterprise and shuttle_15 routers, highlighting the Frame Relay RSRB 


portions. This is the only difference between this model and the TCP model that you just 
performed. 
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Example 13-19 RSRB Frame Relay Encapsulation 


hostname enterprise 
! 


ip subnet-—zero 
! 


source-bridge ring-group 100 


! 
<<<text omitted>>> 

! 

interface Serial0O 

mtu 4096 

no ip address 

no ip directed—-broadcast 
encapsulation frame-relay 

no ip mroute-cache 

logging event subif-link-status 
logging event dlci-status-change 
frame-relay lmi-type cisco 

! 

interface Serial0O.1 multipoint 

ip address 172.16.2.5 255.255.255.252 
no ip directed—-broadcast 


frame-relay map ip 172.16.2.6 170 broadcast 
! 
<<<text omitted>>> 

! 

interface TokenRing0O 

ip address 172.16.10.1 255.255.255.0 
no ip directed-broadcast 

ring-speed 16 

multiring all 

source-bridge 1 1 100 

source-bridge spanning 


hostname shuttle_15 
! 
ip subnet-—zero 
! 
source-bridge ring-group 100 
! 
interface Serial0 
mtu 4096 
ip address 172.16.2.6 255.255.255.252 
no ip directed-broadcast 
encapsulation frame-relay 
no ip route-cache 
no ip mroute-cache 
logging event subif-link-status 
logging event dlci-status-—change 


frame-relay map ip 172.16.2.5 171 broadcast 
! 


<<<text omitted>>> 
! 
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interface TokenRing0O 

ip address 172.16.1.1 255.255.255.0 
no ip directed-broadcast 

no ip route-cache 

no ip mroute-cache 

ring-speed 16 

multiring all 

source-bridge 15 10 100 
source-bridge spanning 


The status of the RSRB can be viewed with the same show source-bridge command used 
earlier. Example 13-20 lists the output of this command performed on the enterprise router. 


Example 13-20 Status of the RSRB on the enterprise Router 


enterprise#show source—bridge 


Local Interfaces: receive transmit 
sem bn tin rp Ss A max hops ent ent drops 
ToO 1: 21° L200: * as eo 4223 0 0 


Global RSRB Parameters: 
TCP Queue Length maximum: 100 


Ring Group 100: 
No TCP peername set, TCP transport disabled 
Maximum output TCP queue length, per peer: 100 


Peers: state bg lv pkts_rx pkts_tx expl_gn drops: TCP 

FR Serial0.1 170 open 3 ©) 253 230 16 
n/a 

Rings: 

baz 1 was. local ma: 4007.781la.e789 TokenRingO fwd: 0 

brs. 10 raz 15 remote ma: 4000.309a.68bb FR Serial0O.1 170 fwd: 0 
Explorers: —-----~ amputee SSS S 0 00S output —---—-—— 

spanning all-rings total spanning all-rings total 

To0 1886 2337 4223 ) 0 ) 


Explorer fastswitching enabled 


Local switched: 4223 flushed 0 max Bps 38400 
rings inputs bursts throttles output drops 
To0 4223 0 ) ) 
enterprise# 


Configuring Other SRB Functions and Features 


Cisco provides many useful options for controlling traffic and fine-tuning the source-route bridge 
environment. Some of the more common features are as follows: 


RSRB TCP and LLC2 local acknowledgment 
Setting largest frame 

Setting Spanning Tree explorers 

Static RIFs 

LSAP and MAC filters 
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The sections that follow discuss some of these options and how to use them. 


RSRB TCP LLC2 Local Acknowledgments 


SNA sessions are complete end-to-end sessions. Every frame sent by a front-end processor must 
be acknowledged by the station or controller receiving the frame. If the SNA session must cross 
vast geographical distances over low-speed links such as 64 kpbs, there is a high probability of T1 
timer expirations. The T1 time is a predefined period of time that a host expects the receiving 
host to respond, either positively or negatively, to the frame sent to it. All LLC2 frames, including 
supervisory frames RR, RNR, and REJ, must be acknowledged in an end-to-end manner. Figure 
13-23 represents a typical LLC2 session in an RSRB environment. 


Figure 13-23. LLC2 Session Without Local Acknowledgment 


Cisco offers local acknowledgment for TCP-based RSRBs. Local acknowledgment solves the T1 
timer problem without having to change the configuration of the end nodes. With local 
acknowledgment enabled, all LLC2 frames are acknowledged by the router. The only LLC2 frames 
that cross the network are | frames, or information frames. Figure 13-24 demonstrates LLC2 local 
acknowledgment. 


Figure 13-24. LLC2 Session with Local Acknowledgment 
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To configure local acknowledgment between two RSRBs, use the argument local-ack on the 
source-bridge remote-peer statement: 


Router (config) #source-bridge remote-peer virtual_ring tcp ip_address local-ack 
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Because the router must maintain a full LLC2 session with every host, the number of 
simultaneous sessions that it can support could be a factor. Cisco recommends using local 
acknowledgment only when you are experiencing T1 timer problems or LLC2 problems. Local 
acknowledgment will not affect NetBIOS timeouts. 


Setting the Largest Frame Size 


In mixed environments, such as Token Ring and Ethernet, to prevent a lot of segmentation 
throughout the network, you can fix the largest frame size to 1500 or another value. By setting 
the frame size to 1500, less segmentation will occur as frames cross Ethernet and Token Ring 
segments of the network. This easily is accomplished using the If argument on the Frame Relay, 
TCP, and FST remote-peer statements: 


Router (config) #source-bridge remote-peer virtual_ring frame-relay interface 
interface_name dlci_number [lf largest_frame_size] 

Router (config) #source-bridge remote-peer virtual_ring tcp ip_address 
[lf largest_frame_size] [local-ack] 

Router (config) #source-bridge remote-peer virtual_ring fst ip_address 
[lf largest_frame_size] 


Configuring Spanning Tree Explorers 


By default, Cisco routers use all-routes explorer frames to generate the RIF. In large redundant 
networks, the number of explorers can multiply exponentially as they are duplicated and 
forwarded throughout the network. Recall from the previous section that Spanning Tree explorers 
reduce the number of explorers on the network. Spanning Tree nodes will forward Spanning Tree 
explorers only to nodes that are configured for Spanning Tree. To enable the spanning tree 
explorers, use the following Token Ring interface command: 


Router (config-if) #source-bridge spanning 


Microsoft NetBIOS also uses Spanning Tree; therefore, as a rule of thumb in the field, we always 
configure Spanning Tree explorers when using Microsoft Windows networking. 


Configuring a Static RIF 


Cisco provides a way to statically configure a RIF on a router. To configure a static RIF, you must 
be familiar with route control and route descriptor frames. Recall the figures from the previous 
section of source-route bridging. 


Figure 13-25 illustrates the routing control format for the RIF, followed by the descriptions of each 
field. 


Figure 13-25. RIF Routing Control Format 


e Shaded fields are reserved. 
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e type— Explorer type is used, as follows: 


- 00: Specific routes explorer 
- 10: All rings, all-routes explorer 
- 11: All rings, spanning routes (limited broadcast) 


e length— This is the total length in bytes of the RIF. 
e D-— This is the direction, indicated as follows: 


- O: Interpret route left to right (forward) 
- 1: Interpret route right to left (reverse) 


e largest— This is the largest frame that can be handled by this route, as follows: 


- 000: 516 bytes (DDN 1822) 

- 001: 1500 bytes (Ethernet) 

- 010: 2052 bytes 

- O11: 4472 bytes (Token Ring and Cisco maximum) 
- 100: 8144 bytes (Token bus) 

- 101: 11407 bytes 

- 110: 17800 bytes 

- 111: 65535 (initial values) 


Figure 13-26 describes the routing descriptor format of the RIF string. When you configure a 
static RIF, it is in dotted-hexadecimal format. 


Figure 13-26. Routing Descriptor Format 


8 


Bridge Number 


e Ring number— Unique decimal ring number within the bridged network. 


e Bridge number— Unique decimal bridge number between any bridges connecting the 
same two rings. A bridge number of 0 indicates that the RIF is terminating. 


Figure 13-27 presents an SRB network. 


Figure 13-27. Source-Route Bridge: RIF 
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RIF = 0830.0072.064.2.00b0 
or 
RING?-BRIDGE2-RING100- 
BRIDGE10-RING11 


Bridge 2 Bridge 10 


Tod 


rouler_johnsen Station Brava 
MAC-1000,1000.2000 


The static RIF from router_johnson to station Bravo would read as follows: 


0830.0072.064a.00b0 


Use the previous figures to break down the RIF into its significant components. The 0830 is the 
16-bit RC field. Reading from left to right, the bit pattern is as follows: 


Po ee ee 


The first two bits, from left to right again, equal 00. This sets the explorer type to be a specific 
routes explorer; you want to use this explorer type because this is a static RIF. Bit 3 is set to 0 
and is reserved. The next five bits set the length of the RIF in bytes. In this example, the RIF—not 
just the ring-bridge-ring part, but the whole RIF—is eight bytes. The next bit, the D bit, is set to 
0, indicating that the RIF is read from left to right, or forward. The next three bits are set to 011, 
which sets the frame size to be 4472, the Cisco maximum. The last four bits are reserved. 


The RD fields, the next three bytes, break down rather easily. 


The next three bytes, 0072, 064a, and O0b0, are the three 16-bit RD fields. The first three bits of 
each byte, are the ring number in hexadecimal format. The last bit is the ring number in 
hexadecimal format. For the RIF in this example, you have the following: 


RING7-BRIDGE2 = 0072 
RING100-BRIDGE10 = 064a 
RING11-BRIDGEO = 00b0 


A bridge of 0 tells the SRB to terminate the RIF and that no more bridges follow the ring. 
To configure a static RIF on a router, use the following global router command: 
Router (config) #rif mac-address rif-string {interface-name | ring-group ring} 


Example 13-21 demonstrates the configuration of the static RIF from router_johnson to station 
bravo. 


Example 13-21 Static RI F Configuration 


router_johnson (config) #rif 1000.1000.2000 0830.0072.064a.00b0 to0 876 


LSAP, MAC, and NetBIOS Filters 


We will discuss LSAP and MAC filters more in the upcoming sections. For now, we simply want to 
show you the syntax for applying the filters to a source-route bridge environment. 


To configure LSAP filters for IEEE 802 encapsulated frames, use the following syntax: 


Router (config-if) #source-bridge input-lsap-list access_list_number 

Router (config-if) #source-bridge output-lsap-list access_list_number 

Router (config) #rsrb remote-peer ring-group group [tcp ip_address | fst ip_address | 
interface interface_name] lsap-output-list access_list_number 


The LSAP access lists is in the range of 200 to 299 and filters based on LSAP type code. 
To filter based on |EEE 802 source addresses, use the following syntax: 


Router (config-if) #source-bridge input-address-list access_list_number 
Router (config-if) #source-bridge output-address-list access_list_number 


The access list number ranges from 700 to 799. 

To filter based on NetBIOS name, use the following commands: 

Router (config-if) #netbios input-access-filter host station_name 
Router (config-if) #netbios output—access-filter host station_name 


Router (config) #rsrb remote-peer ring-group [tep ip_address | fst ip_address | 
interface interface_name] netbios-output-list access_list_number 
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Data Link Switching Plus (DLSw+) 


Data Link Switching (DLSw), as we know it today, was pioneered in 1995 by the Advanced Peer-to-Peer 
Networking (APPN) |mplementers' Workshop (AIlW), sponsored by IBM. It was not the first RFC on DLSw. IBM 
wanted to create a way to transport LLC2 frames across TCP/IP networks and drafted RFC 1434 in 1993. The 
concept was sound, but it lacked (surprise) multivendor interoperability. 


The goal of the APPN AIW goal was to evolve the original DLSw RFC, RFC 1434, with new features. The 
original work later was turned into the first standard for DLSw, titled RFC 1795. RFC 1795 defines what 
commonly is called Data Link Switching Version 1. 


DLSw version I| was developed in 1997 and is documented in RFC 2166, which provided enhancements that 
allowed DLSw networks to scale better and provide better availability than either RSRB or standard- only 
implementations. Cisco Systems refers to its implementation of DLSw as DLSw Plus (DLSw+). One of the 
most notable features about DLSw+ is the concept of border peers and peer groups. 


NOTE 


For the purpose of this text, consider DLSw to be synonymous with DLSW Version 1, Version 2, 
and Cisco's implementation's DLSW+. When we discuss material where the version or 
implementation is relevant, we will note that. 


DLSw+ Features 


In 1991, RSRB was the only option that many network engineers had to bridge their Token Ring or LLC2 
networks over an IP-based network. In a short time, thousands of RSRB networks were springing up. Soon, 
however, RSRB networks were sidelined by the newer way to transport LLC2 over an IP network, DLSw. By 
1995, all future work on RSRB glided to a halt because the industry clearly was embracing DLSw. Since then, 
it has surfaced to become the most dynamic and one of the most reliable ways to transport legacy protocols 
across the modern internetwork. 


DLSw provides a method of running SNA and NetBIOS over IP. DLSw also provides better scalability, 
functionality, manageability, and control than RSRB. DLSw addresses several RSRB limitations by including 
key features such as local acknowledgment for devices on Ethernet and SDLC for physical unit (PU) 2.1 
devices. DLSw also provides higher availability with load balancing and backup features. 


Some of the advantages DLSw+ offers over RSRB are as follows: 


Multivendor interoperability 

DLC timeouts 

DLC acknowledgments over the WAN 

Circuit-level flow and congestion control 

Peer priority and port load sharing 

Local acknowledgment on Ethernet 

Backup, dynamic, and fault-tolerant peers 
Enhanced broadcast reduction 

UDP for UI frames 

RIF termination, allowing a wider network diameter 
Broadcast optimization with peer groups and border peer caching 
Enhanced support, including the following: 


- Media conversion built in (PU 2.0, 2.1, and 4) 
- Support for end systems on Token Ring LANE, Token Ring ISL, and SRB FDDI 


- Detailed capabilities exchange 
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- SNA DDR 
NOTE 


DLSw, the Only Way to I ntegrate Legacy Protocols 


In the field, | have found DLSw+ to be one of the most reliable and fairly straightforward 
protocols to configure. SNA is a time-sensitive protocol, and the ease in which DLSw transports it 
across the internetwork is exceptional. When | learned to configure DLSw+, it quickly became 
my only choice for transporting nonroutable protocols, such as SNA, NetBEUI, and NetBIOS. 
Hopefully, when you finish this section, you, too, will feel this way. 


DLSw+ Technical Overview 


IEEE 802.2 LLC Type 2 was designed under the assumption that network transit delay would be small and 
predictable. After all, Token Ring and Ethernet are LAN protocols. When remote bridging is used over vast 
geographical distances, the network delay can vary drastically with the load on the link. When the delay 
becomes too large, LLC2 timeouts occur and retransmissions start happening. Because the frame is only 
delayed, LLC2 can become confused when it starts to see duplicate frames, and it might start tearing down 
LLC2 sessions. Figure 13-28 illustrates how LLC2 has end-to-end acknowledgment in a traditional bridged 


environment. 
Figure 13-28. LLC2 End-to-End Acknowledgment 
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DLSw+ terminates the LLC Type 2 connection on the DLSw+ device/router. LLC Type 2 connections no longer 
cross the WAN and are exposed to large delays. The only delays that occur at the LLC layer are now on the 
LAN. This inherently reduces traffic on the WAN as well. SDLC links, polling, and poll response occur locally 
and no longer transverse the WAN. Broadcasting of search frames is controlled by the DLSw+ router and are 
no longer flooded after the router locates the target station. Figure 13-29 illustrates how acknowledgments 


are handled in a DLSw+ environment. 


Figure 13-29. LLC2 with Local Acknowledgment 
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As mentioned, DLSW-+ provides a method of transport for SNA, NetBIOS, and NetBEUI over TCP/IP. DLSW+ 
refers to routers as peers. When the TCP or other transport protocol makes a connection with another router, 
it is called a peer connection. When this type of peer connection is formed, a DLSw circuit is established 
between the two end stations. Data between the two end stations is passed on the circuit. A single peer can 
support multiple circuits. DLSW+ supports the following circuit types: 


SNA PU Type 2.0/2.1 and SNA PU Type 4 
SDLC PU1 Type 1 through PU Type 4 
NetBIOS 

Windows 9.x NetBEUI 


By default, every 30 seconds, DLSw+ peers send keepalive messages to all peers. The keepalive mechanism 
is used to ensure that the peer is alive. If three keepalives are missed, the peer will be torn down. 


The data-link switch—or Cisco router, in our case—uses a Switch-to-Switch Protocol (SSP) to establish DLSw 
peers. A pair of routers uses a peer connection to multiplex data links over a reliable transport using SSP 
protocol. Before DLSw can occur between two routers, the routers must establish a peer relationship with 
each other. The transport protocol for DLSw peer connections is TCP. The Cisco implementation, DLSW+, 
allows for four types of transport methods: 


e TCP encapsulation— TCP is used where local acknowledgment is required, and it aids in preventing 
data-link control timeouts. TCP also provides backup peers and other capabilities that allow for 
nondistruptive rerouting around link failures. 


TCP is the most flexible and reliable of all the transports. Unfortunately, it also has the most overhead 
because of the 20 bytes for the TCP header, 20 bytes for the IP header, and 16 bytes for the DLSw 
header. |n modern networks, this amount of overhead is becoming irrelevant. DLSw TCP encapsulation 
listens on TCP port 2067 and transmits on TCP port 2065 by default. Priority can be assigned by the 
TCP port number. Table 13-3 lists the ports and the corresponding priority. 


Table 13-2. TCP Port Priority 


| Priority Port 
= [2065 
Medium [1981 

fee 

1983 


TCP encapsulation also allows the most comprehensive control over the capabilities exchanges and 
explorer traffic, by the use of LSAP, DMAC, and NetBIOS name filters. TCP peers can exist on any type 
of LAN or WAN topology that supports TCP/IP. 


e Fast Sequence Transport (FST) encapsulation— FST is a low-overhead method of transporting 
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DLSw over IP. This method does not have reliable delivery of frames or local acknowledgment. All 
keepalive frames flow end to end with FST transport. FST uses IP as the transport and reroutes around 
link failures. FST encapsulation can be used only when the end systems reside on Token Ring. FST 
peers can exist over HDLC, Ethernet, Token Ring, FDDI, ATM, and Frame Relay. 


e Direct encapsulation— Direct encapsulation provides a low-overhead option for transporting LLC 
across HDLC or Frame Relay links. It includes only the 16 byte DLSw header, along with the frame 
header that it is being transported in. The direct method does not have reliable delivery of frames or 
local acknowledgment. As with FST, keepalive frames flow end to end, and direct encapsulation can be 
used only when the end systems reside on Token Ring. 


e LLC2 encapsulation (DLSw Lite)— This method of encapsulation is another low-overhead method, 
16 bytes, utilizing RFC 1490, which allows for direct encapsulation of a protocol in the Frame Relay 
frame. Naturally, this method can be used only over Frame Relay. DLSw+ Lite supports local 
acknowledgment and reliable delivery of frames. Link failures are disruptive to DLSw Lite peers. 


DLSw Circuit Establishment 


Circuit establishment occurs between two end systems. SNA circuit establishment occurs when a SNA TEST or 
XID explorer frame with a specific MAC address is generated from an end station. The DLSw router sends a 
CANUREACH frame to each active peer. The correct peer responds with an |CANREACH frame. After a series 
of XIDs and other information is exchanged, a circuit is established. Each circuit has a unique ID that allows a 
TCP peer connection to support multiple circuits. The 1D is composed of the source and destination MAC 
address, source and destination LSAPs, and a data-link control port 1D. Only when the circuit becomes 
connected can data can be exchanged between the hosts. Each DLSw router caches the MAC addresses and 
NetBIOS names to prevent future explorer frames from crossing the network. Figures 13-30 and 13-31 are 


adopted from RFC 1795 and illustrate the complete process of DLSw circuits for SNA and NetBIOS. 


Figure 13-30. SNA Circuit Establishment 
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Figure 13-31. NetBIOS Circuit Establishment 
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NetBIOS stations establish circuits in a similar manner. Instead of issuing a CANUREACH frame, NetBIOS 
issues a NetBIOS NAME-QUERY frame that specifies a NetBIOS name. Figure 13-31 illustrates the complete 


circuit establishment process for NetBIOS. 
DLSw Capabilities Exchange 


A key process that occurs during DLSw circuit establishment is the capabilities exchange. The capabilities 
exchange the process that differentiates DLSw from other bridging technologies. The exchange is a special 
DLSw SSP control message that describes the capabilities of the sending DLSw router. The initial capabilities 
exchange is always the first SSP message sent when a new connection between two DLSw devices occur. It is 
used to identify the DLSw version and other options that the DLSw device is capable of. 


SSP uses the concept of control vectors to exchange information between DLSw devices. Required control 
vectors must occur first and in the following order: 


1. Vendor ID 
2. DLSw version number 


3. Initial pacing window 
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4. Supported SAP list 


The remainder of the control vectors can occur in any order: 


Vendor ID control vector. 

DLSw version control vector. This indicates the DLSw standard in use. 

Initial pacing window control vector. This is used for flow control. 

Version string control vector. 

MAC address exclusivity control vector. This includes only MAC addresses that this switch can reach. 
Supported SAP list control vector. This is a list of all SAPs. 

TCP connections control vector. This specifies the number of TCP connections to support. 
NetBIOS name exclusivity control vector. 

MAC address list control vector. 

NetBIOS name list control vector. 

Vendor context control vector. 

Reserved for future use. 

Vendor- specific. 


Cisco's implementation of the TCP connections control vector states that only one TCP connection will be used 
to transport data. When a DLSw+ circuit first is established, two TCP connections are active. DLSw+ states 
that the TCP connection with the highest |P address will be torn down, leaving only one TCP connection to 
transport data. 


After the capabilities exchange occurs, the DLSw router can proceed to complete circuit setup. Only after a 
circuit is connected can data be exchanged on it. 


DLSw Flow Control 


DLSw uses a form of adaptive pacing for flow control. DLSw specifies two independent, unidirectional circuit 
flow-control mechanisms on a per-circuit basis. DLSw uses a dynamic window based on buffer size, TCP 
transmit queue, and end station flow-control mechanisms. 


DLSw RIF Termination and RIF Passthrough 


DLSw supports RIF termination when used with source-route bridges. All remote devices/bridges appear to be 
attached to the virtual ring. By default, the RIF is terminated by the DLSw router. DLSw peers also can be 
configured to have RIF passthrough. When configuring RIF passthrough, be sure that the virtual rings on both 
peers match and that both peers have RIF passthrough enabled. 


Canonical and Noncanonical Address Formats 


Recall from Chapter 2 that Ethernet uses canonical bit format and Token Ring uses noncanonical format. 
When DLSw receives a frame from Ethernet, it converts it to noncanonical format. DLSw works strictly in 
noncanonical format as it passes data from peer to peer. When the frame arrives at the interface it is destined 
for, DLSW checks to see whether the interface is Ethernet or Token Ring. If the interface is Ethernet, the 
frame is converted back to canonical format and is sent out the interface. If the interface is Token Ring, the 
frame is passed unchanged to the Token Ring interface. Care should be taken whenever using SNA attached 
Ethernet devices so that they operate in canonical format. Most SNA devices, such as IBM 3174s, do operate 
in canonical format on Ethernet. 


Configuring DLSw+ 


For the purpose of this text, we will discuss configuring DLSw only with Token Ring and Ethernet networks. 
For comprehensive information on configuring DLSw for FDDI, SDLC, and QLLC, see Cisco 1OS Bridging and 
IBM Network Solutions, by Cisco Press. 


Configuring DLSw involves a four-step task. Essentially, you need to create a bridge for the LAN interface and 
define local and remote DLSw peers. Naturally, there will be a few steps in between, but basically, that is all 
there is to configure for DLSw. This might again explain why it has become so popular so quickly. 
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The four-step task lists the steps necessary to configure DLSw: 


Step 1. Configure IP loopback interfaces, and add them to the routing domain on every router that 
you want to enable DLSw on. As in RSRB and OSPF, the use of loopback addresses provides greater 
stability for the DLSw peers. Using logical interfaces, the DLSw peer connections are not dependent on 
the operational status of a physical interface. This can be important on multi-interfaced routers. Be 
sure that the loopback's IP address is reachable by the remote peer router. We usually circulate 
loopback addresses with a routing protocol. 


Step 2. Define a local peer for DLSw. The creation of a local peer activates the DLSw code in the 
router. The local peer's IP address should be that of the loopback interface configured in Step 1. The 
local peer is where you specify all local DLSw+ parameters. The basic syntax needed for a DLSw is 
listed, followed by the syntax of the whole command. We will talk about most of these additional 
arguments in upcoming sections. 


Router (config) #dlsw local-peer [peer-id ip_address] 

Router (config) #dlsw local-peer [peer-id ip_address] [group 

peer_group_1-255] 
[border] [cost 1-5] [1f largest_frame_516-11407] [keepalive seconds] 
[passive] [promiscuous] [init-pacing-window size_1-2000] 
[max—pacing-window size] [biu-segment ] 


Step 3. Enable transparent bridging for Ethernet interfaces, and/or enable source-route bridging for 
Token Ring interfaces. The source-route bridge automatically is linked to DLSW through the virtual 
ring. The Ethernet transparent bridge needs to have additional syntax to link it to DLSw, as noted 
later. You can think of the bridge as a broadcast or LLC2 capture entity. When the frame is captured, it 
can be transported to the remote peer. Traffic from a remote peer is forwarding only into the virtual 
ring or transparent bridge group defined by the dlsw bridge-group command. For more information 
on transparent and source-route bridging, see the previous sections on those topics. 


Ethernet: Enable transparent bridging on the Ethernet interface running SNA, NetBIOS, or 
another LLC2 protocol. This example uses bridge 10. 


Router (config) #bridge 10 protocol ieee 
Router (config) #dlsw bridge-group 10 
Router (config-if) #bridge-group 10 


- The full syntax for the dlsw bridge-group command is as follows: 


Router (config)# dlsw bridge-group group-number [1lc2 [N2 number] 
[ack-delay-time milliseconds] [ack-maxnumber] 

[idle-time milliseconds] [local-window number] 

[t1l-time milliseconds] [tbusy-timemilliseconds] 

[tpf-time milliseconds] [trej-time milliseconds] 

[txq-maxnumber] [xid-neg-val-time milliseconds] 

[xid-retry-time milliseconds]] [locaddr-priority 

lu address priority list number] [sap-priority 

priority list number] 


Token Ring: Enable source-route bridging on the Token Ring interface running SNA, NetBIOS, 
or another LLC2 protocol. You must define a virtual ring for SRB. This example creates a virtual 
ring of 100, and the ring number of the Token Ring interface is 1. 


Router (config) #source-bridge ring-group 100 
Router (config—if) #source-bridge 1 2 100 


Step 4. Decide what encapsulation type you will use for the peers. As mentioned previously, you have 
four types of encapsulation to choose from. Table 13-3 lists the various encapsulation types, along 


with some of the capabilities supported with that encapsulation type. 
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Table 13-3. DLSw Encapsulation Support Matrix 


Nondisruptive End- 
Rerouting [Overhead | station 
Encapsulation |Reliable Local | Around Link | Of era Topology | Backup 
Delivery | Ack Failures [**] 


Yes 56 bytes 
Nott! 36 bytes {Token Ring |Yes 
only 


ia No 16 bytes |Token Ring |No 


DLSw Lite Nol 20 bytes’ {Token 
Ring, 
Ethernet, 


[**] Overhead does not include the DLC or frame headers on the overhead associated 
with DLSw. 


1 FST and DLSw can be configured in manners to provide disruptive rerouting around link 
failures. Note that the session will drop during disruptive rerouting. 


Use the following global configuration commands to configure the variousencapsulation types on the remote 
peer. The IP address of the remote peer should be the IP address of the loopback interface of the remote 
router. The first command in each list shows the minimum configuration needed for the remote peer, followed 
by the complete syntax of the remote peer statement for that encapsulation type. 


- TCP encapsulation: 


Router (config) #dlsw remote-peer 0 tcp ip_address 

Router (config) # dlsw remote-peer list-number tcp ip-address [backup-peer 
[ip-address | frame-relay interface serial number dlci-number | 
interface name]] [bytes-netbios-out bytes-list-name] 

[circuit-weight weight] [cluster cluster-id] 

[cost cost] [dest-mac mac-address] 

[dmac-output-list access-—list-—number] 

[host-netbios-out host-list-name] [inactivity] 

[dynamic] [keepalive seconds] [1f size] [linger 

minutes] [lsap-output-list list] [no-llc 

minutes] [passive] [priority] [rif-passthru 

virtual-ring-number] [tcp-queue-max size] 

[timeout seconds] 


- FST encapsulation: 


Router (config) #dlsw remote-peer 0 fst ip_address 

Router (config)# dlsw remote-peer list-number fst ip-—address 
[backup-peer [ip-address] [bytes-netbios-outbytes—list—name] 
[circuit-weight weight] [cost cost] [dest-mac 

mac-address] [dmac-output-list access—list—number] 
[host-—netbios-out host-list-name] [keepalive seconds] 

[1£ size] [linger minutes] [lsap-output-list list] 


- Direct encapsulation for Frame Relay: 
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You also must add a frame-relay map dlsw statement, if the interface is a multipoint interface: 


Router (config)#dlsw remote-peer 0 frame-relay interface serial number 
DLCI_number 
Router (config-if) #frame-relay map dlsw DLCI_number 


- Direct encapsulation for HDLC: 


Router (config) #dlsw remote-peer O interface serial number 
Router (config) # dlsw remote-peer list-—number interface 

serial number [bytes-netbios-out bytes-—list-—name] 
[circuit-weight weight] [cost cost] [dest-mac mac-address] 
[dmac-output-list access—list-—number] 

[host—netbios-out host-list-name] [keepalive seconds] [1f size] 
[linger minutes] [lsap-output-list list] pass-thru 


LLC2 encapsulation for Frame Relay (DLSw Lite): You also must add a frame-relay map IIc2 
statement if the interface is a multipoint interface: 


Router (config) #dlsw remote-peer 0 frame-relay interface serial 

number DLCI_number 
Router (config-if) #f£rame-relay map 11lc2 DLCI_number 
dlsw remote-peer list-number frame-relay interface serial number 
dlci-number [bytes-netbios-out bytes-list-name] [circuit-weight weight] 
[cost cost] [dest-mac mac-address] [dmac-output-list access-—list—number] 
[host-netbios-out host-list-name] [keepalive seconds] [1f size] 
[linger minutes] [lsap-output-list list] pass-thru 


Practical Example: DLSw TCP and FST Peers 


Figure 13-32 models a Frame Relay network connecting four routers. In this model, you will want to create 


two types of DLSw connections. From the router skywalker, you want to create a TCP peer to the router solo. 
From the vader router, you want to create an FST peer to the router chewbacca. 


Figure 13-32. DLSw TCP and FST Peers 
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Begin by focusing the TCP peer between skywalker and solo. Following the four-step configuration process, 
begin by creating loopback interfaces on skywalker and solo. When the loopback interfaces are configured and 
|P addresses are assigned to them, make sure that they are advertised by the routing protocol. The loopback 
address will serve as the local and remote peers, so it is essential that IP connectivity exits between them. In 
this model, you are using EIGRP as the routing protocol, so EIGRP must advertise all loopback addresses. 
Before moving on to Step 2, be sure that you can ping all the relevant IP addresses in the model. You do not 
want to waste time troubleshooting peers if IP connectivity does not exist. 


In Step 2, you configure the DLSw local peer for each router. Remember, the IP address that you will use will 
be the loopback addresses. To configure the local peer, use the global configuration command dlsw local- 
peer peer-id ip address. For example, to configure the local peer for the skywalker router, enter disw local- 
peer peer-id 172.16.128.5. 


After the local peers are configured, define a transparent bridge group. For Ethernet networks, you must 
configure transparent bridging on the Ethernet segment where the end stations reside. The transparent bridge 
group then is linked to DLSw with the global command disw bridge-group bridge-group. Example 13-22 
lists the relevant portions of the configuration of the solo router, up to this point. 


Example 13-22 DLSw TCP Configuration of the solo Router 


hostname solo 
! 


<<<text omitted>>> 
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interface Loopback20 

ip address 172.16.128.9 255.255.255.252 

no ip directed-broadcast 

! 

interface Ethernet0 

ip address 172.16.6.1 255.255.255.0 

no ip directed-broadcast 

bridge-group 1 “Transparent Bridging enabled for BO 
! 

interface Serial0 

ip address 172.16.1.6 255.255.255.0 

no ip directed-broadcast 

encapsulation frame-relay 

no ip mroute-cache 

frame-relay map ip 172.16.1.5 131 broadcast 
frame-relay map ip 172.16.1.1 131 broadcast 
frame-relay lmi-type cisco 

! 

<<<text omitted>>> 

! 
router eigrp 65001 

network 172.16.0.0 

no auto-summary 

! 
ip classless 


no ip http server 
! 


bridge 1 protocol ieee = =) “Transparent Bridging enabled 
! 


To configure the remote peer for TCP, use the global command disw remote-peer 0 tcp ip address. Unless 
you are using a DLSw port list, use 0, which implies that no list is in use. The previous example demonstrated 
the use of this command on the solo router. Example 13-23 lists the configuration of the skywalker router. 


Example 13-23 DLSw TCP Configuration of the skywalker Router 


hostname skywalker 
! 


<<<text omitted>>> 


interface Loopback20 

ip address 172.16.128.5 255.255.255.252 
! 
interface Ethernet0O 

ip address 172.16.5.1 255.255.255.0 


! 
interface Serial0 

ip address 172.16.1.5 255.255.255.0 
encapsulation frame-relay 

no arp frame-relay 

frame-relay map ip 172.16.1.6 111 broadcast 
frame-relay map ip 172.16.1.1 111 broadcast 
no frame-relay inverse-arp 

frame-relay lmi-type cisco 

! 

<<<text omitted>>> 

! 
router eigrp 65001 


network 172.16.0.0 
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no auto-summary 
! 


<<<text omitted>>> 
! 


bridge 1 protocol ieee 


To verify the configuration, you can view the status of the peers with the show dlisw peers command. 
Example 13-24 displays the output of this command on the solo router. Only when the peer is in a connect 
state can it create a circuit transport data. It is important to note that a "connected peer" does not mean that 
DLSw is fully functional. DLSw circuits, denoted by the ckts column, are the only indication that an end-to-end 
session exists within a TCP peer. We will discuss this command more in the next section. 


Example 13-24 show disw peers Command Output 


solo#show dlsw peers 
Peers: state pkts_ rx pkts_tx type drops ckts TCP uptime 


TEP IZ Me 128.35 CONNECT 299 444 conf 0 ul © OOFS9539 


Total number of connected peers: 1 
Total number of connections: il 


solo# 


Example 13-25 demonstrates another way to view more comprehensive information about a DLSw circuit. The 
command used in this example is show dlsw circuits. 


Example 13-25 show dlisw circuits Command Output 


solo#show dlsw circuits 

Index local addr(lsap) remote addr(dsap) state uptime 
1778384900 0000.613c.dc82(F0) 0005.332e.2a25(F0) CONNECTED OOS 227 
Total number of circuits connected: 1 


NOTE 


In this model, we use Windows 98 workstations with NetBEUI and Windows networking enabled 
to create DLSw circuits. Using Windows networking provides a great application for testing DLSw. 
To actually create a circuit, you must browse the network neighborhood and log into that 
workstation and access a network resource, such as viewing a drive. It is important to test your 
network with as many real applications as possible. This is the only way to actually tell whether 
your configurations are successful. For example, in this model, if you did not have workstations, 
you would never see a circuit be created. So, you might be thinking, "This is okay—I can status 
the peers and DLSw capabilities, and get a good idea that my configuration works." But let's just 
say you forgot to enable bridging on the Ethernet interface. The peer will still become active, 
and, really, from a DLSw point of view, everything is configured properly. However, because of 
this critical error, DLSw forwards any traffic to the Ethernet segment. Figure 13-33 displays the 
workstation R2-D2 finding and then viewing the files on luke. 


Figure 13-33. Using Windows 9x to Test DLSw 
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To configure the FST peer in the model, you can begin adding the loopback interfaces and addresses to the 
vader and chewbacca routers. 


In Step 2, you add a local peer to each router, pointing at the loopback interface just created. The command 
for a local FST peer is identical to that of a TCP peer. For example, on the vader router, the syntax would be 
disw local-peer peer-id 172.16.128.1, and on the chewbacca router, it would be dlsw local-peer peer-id 
172.16.128.13. 


The next step is to configure source-route bridging using a virtual ring for all the interfaces that have end 
stations on them. The virtual ring is the link that ties DLSw to the source-route bridge. There is no need to 
configure a command similar to the dlsw bridge-group command. 


Step 4 calls for configuring a DLSw remote FST peer. The syntax to accomplish this on the chewbacca router 
would be dilsw remote-peer 0 fst 172.16.128.1. Example 13-26 lists the configurations of the chewbacca 


and vader routers, respectively. 


Example 13-26 FST Peer Configurations of the chewbacca and vader Routers 


hostname chewbacca 
! 


<<<text omitted>>> 


interface Loopback20 
ip address 172.16.128.13 255.255.255.252 
! 
interface Serial0 
ip address 172.16.2.2 255.255.255.252 
encapsulation frame-relay 
frame-relay interface-dlci 181 
frame-relay lmi-type cisco 
! 
<<<text omitted>>> 
! 
interface TokenRingO 
ip address 172.16.3.1 255.255.255.0 


ring-speed 16 890 


source-bridge 11.2111 = =~ sB enabled 
source-bridge spanning 

! 
router eigrp 65001 

network 172.16.0.0 


no auto-summary 
! 


hostname vader 
! 


<<<text omitted>>> 


interface Loopback20 

ip address 172.16.128.1 255.255.255.252 
no ip directed-broadcast 

! 

<<<text omitted>>> 

! 
interface Serial0 

no ip address 

no ip directed-broadcast 
encapsulation frame-relay 

no ip mroute-cache 

logging event subif-link-status 
logging event dlci-status-—change 
frame-relay lmi-type cisco 

! 
interface Serial0.1 multipoint 

ip address 172.16.1.1 255.255.255.0 
no ip directed-broadcast 

no ip split—horizon eigrp 65001 
frame-relay map ip 172.16.1.5 110 broadcast 
frame-relay map ip 172.16.1.6 130 broadcast 
! 
interface Serial0.2 point-to-point 

ip address 172.16.2.1 255.255.255.252 
no ip directed-broadcast 

frame-relay interface-dlci 180 

! 
<<<text omitted>>> 

! 
interface TokenRingO 

ip address 172.16.30.1 255.255.255.0 
no ip directed-broadcast 

ring-speed 16 


source-bridge spanning 
! 


<<<text omitted>>> 
! 

router eigrp 65001 
network 172.16.0.0 


no auto-summary 
! 


Again, to view the status of a peer, you can use the show dlsw peer command, as shown in Example 13-27. 


Example 13-27 Status of the FST Peer on the chewbacca Router 


chewbacca#show dlsw peers 
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Peers: state pts. rx pkts_tx type drops ckts TCP uptime 
FST 172.116.1281 CONNECT 1635 1371. cont 0 1 = O22 23508 


Expected: 230 Next Send: 194 Seq errors: 0 
Total number of connected peers: 1 
Total number of connections: all 


chewbacca# 


The "Big show" and "Big D" for DLSw+ 


The show and debug commands for DLSw+ are comprehensive; there are many commands and 
subcommands for debugging and display DLSw+ info. Again, instead of listing every possible show and 
debug command relating to DLSw, we will focus on just a few, or the "Big show" and "Big D." For reference, 
the examples presented in the sections on each of these significant show and debug commands are 
generated from the previous model. 


The "Big D" for DLSw consists of debug disw peers, debug disw core, debug disw reachability, and 
their subcommands. As with all debug commands, the output can be rather plentiful, so make sure that 
logging is enabled with the global configuration command logging buffered 10000. 


The syntax for the "Big show" and the "Big D" is as follows: 


show dlsw peer [interface interface_name | ip-address ip_address_of_peer] 

show dlsw reachability [mac-address mac_address] [netbios-name name] 

show dlsw circuits [detail] [circuit_number] [mac-address address | sap-value value 
| circuit_id] 

show dlsw capabilities [interface type number | ip_address ip_address | local] 
debug dlsw peers [interface type number | ip_address ip_address ] 

debug dlsw reachability [error | verbose] [netbios | sna] 

debug dlsw core [flow-control | messages] [state | xis] 


show disw peer Command 


This command displays current peer information for static peers and connected peers. The output in Example 
13-28 lists the peer type, TCP, FST, or interface number for direct encapsulated peer. The type field describes 
whether the peer is configured, promiscuous, or a peer on demand (POD). 


Example 13-28 show disw peer Command Output 


skywalker#show dlsw peer 
Peers: state pktsiex pkts_tx type drops ckts TCP uptime 


TCP 272.16. 028.39 CONNECT 1863 847 conf 0 il 0: 04319326 


Total number of connected peers: 1 
Total number of connections: 1 


The possible states that a peer can be in are as follows: 


e Connect— The DLSw peer is up and has a transport active to the peer. This is the normal state that a 
peer should be in. 


e DISCONNECT— The local peer does not have a valid or active transport to the remote peer. 


e CAP_EXG— The local peer is in the capabilities exchange mode with the remote peer. It is awaiting a 
capabilities response. 


e WAIT_RD— This is the final step in peer establishment. The local peer's TCP write pipe, TCBgprt 


2065, is waiting for the remote peer to open the read port, TCP port 2067. 
e WAN_BUSY— The TCP outbound queue is full, and the packet cannot be transmitted. 


The show dlisw peer also displays the number of packets transmitted and received, along with drops. The 
TCP column is the TCP queue for the peer. This number should remain low, less than 10 and at 0 a majority of 
the time. A high TCP number is an indication of congestion or throughput problems to the remote peer. The 
ckts column lists the number of active circuits on the peer. 


show dlsw reachability Command 


This command is useful when verifying what end stations DLSw has in its current cache. The reachability 
cache is a table that the DLSw checks when it receives a request to initiate a session. It checks the cache in 
an attempt to locate the resource requested. If the destination address is not in the cache, DLSw queries its 
peers. Example 13-29 lists the output of this command. 


Example 13-29 show disw reachability Command Output on the solo Router 


solo#show dlsw reachability 
DLSw Local MAC address reachability cache list 


Mac Addr status Loc. port rit 
0000.613c.dc82 FOUND ,OCAL TBridge-001 ==no: ‘rait== 
0006.3acf.7aa6é FOUND ,OCAL TBridge-001 ==nor- Paira= 


DLSw Remote MAC address reachability cache list 
Mac Addr status Toes peer 
0005.332e.2a25 FOUND REMOTE 172.16.128.5(2065) max-l1f (1500) 


DLSw Local NetBIOS Name reachability cache list 
NetBIOS Name status Loc. porte rif 
R2-D2 FOUND LOCAL TBridge-001 ==—no. Frit== 


DLSw Remote NetBIOS Name reachability cache list 
NetBIOS Name status Loc. peer 
LUKE FOUND REMOTE 172.16.128.5(2065) max—1lf (1500) 


solo# 


The Status field describes the local peer's relationship with that entry. The Location field describes whether 
the end station is considered local or remote to the router. The possible values for the status field are listed 
here: 


e FOUND-— The router has located the end station. 

e NOT_FOUND-— The end station has not responded to queries from this router or peer. 
e SEARCHING— The router is sending queries for the station in an attempt to locate it. 

e UNCONFI RMED-— The station is a static entry, such as with a DLSW ICANREACH entry. 
e WERIFY— Cache is going stale, and the router is verifying it. 


Other information includes the displaced peer/port or the peer the station is accessible from. The RIF and 
largest frame also are listed. The value —no rif— in the RIF fields means that the station does not support a 
RIF, such as an Ethernet station. 


It is important to note that this information is cached, so entries will be aged and flushed. If a station 
currently is sending or trying to send data, it should be listed in the output of the command. 


show dlsw circuits Command 
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Use this command to display end-to-end sessions of peers using TCP encapsulation or Frame Relay direct 
encapsulation with local acknowledgment. This command displays the local MAC address and remote address 
along with SAP that they are using. Example 13-30 lists the circuit between the workstations luke and R2-D2. 


The SAP value is (FO), for NetBIOS. The second half of the example shows the detailed listing of circuit. 


Example 13-30 show disw circuits Command Output on solo Router 


solo#show dlsw circuits 

Index local addr(lsap) remote addr(dsap) state uptime 
2919235595 0000.613c.dc82(F0) 0005.332e.2a25(F0) CONNECTED COOOL 217 
Total number of circuits connected: 1 


solo#tshow dlsw circuits detail 


Index local addr(lsap) remote addr(dsap) state uptime 
2919235595 0000.613c.dc82(F0) 0005.332e.2a25(F0) CONNECTED 00:01:28 
PCEP: 49AC68 UCEP: 142AFC 
Pores TBI peer 172.16.128.5 (2065) 


Flow-Control-Tx CW:20, Permitted:39; Rx CW:20, Granted:29; Op: Repeat 
Congestion: Low(02), Flow Op: Half: 0/0 Reset 0/0 


RIF = —=no rit—= 
Bytes: 2702/6467 Info-frames: 41/31 
XID-frames: 0/0 UInfo-frames: 0/0 


Total number of circuits connected: 1 


solo# 


Circuits can be in one of two states, CONNECTED or CKT_ESTABLISHED. When the circuit is registering as 
CKT_ESTABLISHED, DLSw has set up the circuit properly, but the end stations have not, or cannot, initiated a 
session across the circuit. A restart of the end station might help clear this condition. 


show dlsw capabilities Command 


This command lists the control vectors that the local peer will exchange with other peers during the 
capabilities exchange. The output of this command is useful when SAP and NetBIOS filters are applied to 
DLSw peers. Example 13-31 lists the output of this command. 


Example 13-31 show dlisw capabilities Command Output on solo Router 


solo#show dlsw capabilities 
DLSw: Capabilities for peer 172.16.128.5 (2065) 


vendor id (OUI) : “00C" (elsco) 
version number 2 
release number = 10 
init pacing window + 20 
unsupported saps : none 
num of tcp sessions 2. 4 
loop prevent support : no 
icanreach mac-exclusive : no 
icanreach netbios-excl. : no 
reachable mac addresses : none 
reachable netbios names : none 
V2 multicast capable > yes 
DLSw multicast address : none 
cisco version number = ol 
peer group number : 0 
peer cluster support = 26 
border peer capable : no 
peer cost 3 3 
biu-segment configured : no 
UDP Unicast support > yes 
Fast-switched HPR supp. : no 


NetBIOS Namecache length : 15 894 


local-ack configured : yes 


priority configured nO 

cisco RSVP support = no 

configured ip address ¢ 272 .16.12855 
peer type 2 ‘Conk 


version string : 
Cisco Internetwork Operating System Software 
IOS (tm) 2500 Software (C2500-JS-L), Version 12.1(2)T, RELEASE SOFTWARE (fcl) 
Copyright (c) 1986-2000 by cisco Systems, Inc. 
Compiled Tue 16-May-00 15:28 by ccai 


debug disw peers Command 


Figures 13-30 and 13-31 from the previous section can be useful when used in conjunction with the debugs 
listed. Use the figures as a guide to help you locate where in the data flows you might be having a problem. 


This command provides comprehensive information about the peer status and current actions. Use this 
debug when a peer will not connect or stay active. Example 13-32 lists the output from the debug DLSw 


peers during a NetBIOS session establishment. 


Example 13-32 debug disw peer Command Output During NetBIOS Session 
Establishment 


solo#debug dlsw peers 

DLSw peer debugging is on 

solo# 

01:55:59: %SYS-5-CONFIG_I: Configured from console by console 

01:55:59: SLINEPROTO-5—-UPDOWN: Line protocol on Interface DLSw Port0O, changed state 
tO up 

DLSw: passive open 172.16.128.5(11000) -> 2065 


01:56:00: DLSw: dtp_action_c() opening write pipe for peer 172.16.128.5(2065) 
01:56:00: DLSw: END-TPFSM (peer 172.16.128.5(2065)): state:DISCONN->WWR_RDOP 


01:56:00: DLSw: Asynce Open Callback 172.16.128.5(2065) => 11010 
01:56:00: DLSw: START-TPFSM (peer 172.16.128.5(2065)): event: TCP-WR PIPE OPENED 
01:56:00: DLSw: dtp_action_i() write pipe opened for peer 172.16.128.5(2065) 


01:56:00: DLSw: END-TPFSM (peer 172.16.128.5(2065)): state:WWR_RDOP->WAIT_CAP 


01:56:00: DLSw: START-TPFSM (peer 172.16.128.5(2065)): event:SSP-CAP MSG RCVD st 
ate:WAIT_CAP 
O1F56200% DLSw:s dtp iaction_]() cap msg revd. from peer 172.16.128.5 (20659) 
01:56:00: DLSw: Recv CapExId Msg from peer 172.16.128.5(2065) 

01:56:00: DLSw: received fhpr capex from peer 172.16.128.5(2065): support: false 
, £st-prio: false 

01:56:00: DLSw: Pos CapExResp sent to peer 172.16.128.5(2065) 

01:56:00: DLSw: END-TPFSM (peer 172.16.128.5(2065)): state:WAIT_CAP->WAIT_CAP 


01:56:00: DLSw: START-TPFSM (peer 172.16.128.5(2065)): event:SSP-CAP MSG RCVD st 
ate:WAIT_CAP 
01256300: DLSw: dtplaction_)}() cap msg revd. from peer 172.16.128.5 (2065) 
01:56:00: DLSw: Recv CapExPosRsp Msg from peer 172.16.128.5(2065) 

01:56:00: DLSw: END-TPFSM (peer 172.16.128.5(2065)): state:WAIT_CAP-—>WAIT_CAP 


01:56:00: DLSw: Processing delayed event:SSP-CAP EXCHANGED —- prev state:WAIT_CAP 


01:56:00: DLSw: START-TPFSM (peer 172.16.128.5(2065)): event:SSP-CAP EXCHANGED s 
tate:WAIT_CAP 

01:56:00: DLSw: dtpuaction_k() cap xchged for peer 172.116.1285 (2065) 

01:56:00: DLSw: closing read pipe tcp connection for peer 172.16.128.5(2065) 
01:56:00: DLSw: END-TPFSM (peer 172.16.128.5(2065)): state:WAIT_CAP-—>PCONN_WT 


01:56:00: DLSw: Processing delayed event: TCP-PEER CONNECTED —- prev state:PCONN_W 
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01:56:00: DLSw: START-TPFSM (peer 172.16.128.5(2065)): event:TCP-PEER CONNECTED 
state: PCONN_WT 

01:56:00: DLSw: dtp_action_m() peer connected for peer 172.16.128.5(2065) 
01:56:00: DLSw: END-TPFSM (peer 172.16.128.5(2065)): state:PCONN_WT->CONNECT 


01:56:31: DLSw: dtp_action_q() keepalive request from peer 172.16.128.5(2065) 
01:56:31: DLSw: Keepalive Response sent to peer 172.16.128.5(2065) ) 
01:56:31: DLSw: END-TPFSM (peer 172.16.128.5(2065)): state: CONNECT-—>CONNECT 


debug disw reachability Command 


This command provides a clear picture of the end station's MAC address and the associated SSAPs and 

DSAPs. The debug also provide information on the message type that is being issued by that end station. Use 
this debug if end stations are not showing up in the DLSw reachability cache. Example 13-33 demonstrates 
the output from this command 


Example 13-33 debug disw reachability Command Output During a NetBIOS 
NAME_ QUERY 


solo#debug dlsw reachability 

DLSw reachability debugging is on at event level for all protocol traffic 
09:51:40: CSM: Received CLSI Msg : UDATA_STN.Ind dlen: 79 from DLSw Port0O 
09:51:40: CSM; smac 0000.613c.dc82, dmac c000.0000.0080, ssap FO, dsap FO 
09:51:40: CSM: Received frame type NETBIOS NAME QUERY from 0000.613c.dc82, DLO 
09:51:40: CSM: Received CLSI Msg : CONECT_STN.Ind dlen: 47 from DLSw Port0O 
09:51:40: CSM: smac 0000.613c.dc82, dmac 0005.332e.2a25, ssap FO, dsap FO 
09:51:43: CSM: Received CLSI Msg : UDATA_STN.Ind dlen: 86 from DLSw Port0O 
O9251343 5% ‘CSM: smac 0006.3acf.7aa6, dmac ffff.ffff.ffff, ssap AA, dsap AA 


debug disw core Command 


This command provides visibility to virtually everything that is occurring in the DLSw code. If no 
subcommands are added, all core debugging is enabled. Naturally, this command generates a lot of output 
and should be used to narrow down specific problems. Again, use this command in the field only with console 
logging buffered. 


DLSw+ Advanced Configuration 


DLSw provides many features that allow for easier peer configuration, explorer control, and backup and 
filtering capabilities. This section covers configuration of some of the more advanced features of DLSw+. 
These features include the following: 


DLSw+ promiscuous peers configurations 

DLSw+ backup configurations 

DLSw+ border peers, peer groups, and demand peers 

Controlling DLSw explorers with ring lists, bridge group lists, and port lists 
DLSw+ dynamic peers 

Configuring DLSw+ reachability with the icanreach command 


DLSw+ Promiscuous Peer Configuration 


DLSw-+ allows you to configure different types of peers. The peer types that you have configured up to this 
point have been static peers. That is, a remote peer needs to be defined for every DLSw peer that you want 
to connect to. In large DLSw networks, where there are many peers, this type of configuration can be rather 
lengthy. When a local peer is configured in promiscuous mode, it automatically accepts peer connections from 
remote peers without having a specific remote peer configured. To configure a local peer as promiscuous, use 
the following syntax: 


Router (config) #dlsw local-peer peer-id ip_address promiscuous 
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Figure 3-34 illustrates a DLSw+ network, with the vader router using its local peer as promiscuous. With the 
local peer as promiscuous, there is no need to configure any remote-peer statements for the skywalker, 
solo, and chewbacca routers. The remote routers, however, still need a remote-peer statement pointing at 
the promiscuous peer. 


Figure 13-34. Promiscuous Peers 
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chewbacca 
LB20-IP=172.16.128.5/30 


disw local-peer peer-id 172.16.128.5 
disw remote-peer 0 top 172.16.128.1 


LB20-IP=172.16.128.13/30 


| disw local-peer peer-id 172.16.128.13 
disw remote-peer 0 tcp 172.16.128.1 


solo 
LB20-\P=172.16.128,9/30 


disw local-peer peer-id 172.16.128.9 
disw remote-peer 0 tcp 172.16.128.1 


Promiscuous peers have standard default values for all remote peers that connect to them. For example, use 
this command if you want to change keepalive values or other such parameters for the remote peers that 
connect to the promiscuous peers. To change these default values or apply access lists, use the following 
syntax: 


Router (config) #dlsw prom-peer-defaults [bytes-netbios-out bytes-—list-—name] [cost 1-5] 
[dest-mac destination_mac_address] [dmac-output-list access-—list-—number] 
[host-netbios-out host-list-name] [keepalive seconds] [1f largest_frame_516-11407] 
[LSAP-output-list list] [tcp-queue-max size] 


DLSw+ Backup Configurations 


DLSw offers a couple of methods to configure redundancy, depending on whether you want to keep the DLSw 
peer active. One method is configuring a peer as a backup peer. When a peer is configured as backup, it 
becomes active only when the router loses connectivity to the primary peer or DLSw router. The other 
method is used primarily to provide peer stability during a link failure. In this method, you tweak DLSw 
timeout and keepalives, to essentially keep the peer up during a routing protocol convergence, or during the 
time that it takes to activate a DDR or backup link. 


DLSw+ Backup Peers 


Backup peers are created by simply adding the backup-peer argument to the new remote peer. Before 
creating a backup peer, you must define the primary peer. The backup peer must point at a different DLSw 
router than the primary peer. The linger keyword tells the router not to disconnect the backup peer until the 
primary has been up for X amount of seconds. Without the linger keyword, the primary peer immediately 
becomes active when connectivity is restored. 


LLC2 sessions automatically are terminated when the linger timer expires, and this can be an undesirable 
result of the backup peer. If the linger keyword is omitted, the backup peer stays active when the primary 
peer comes online, but no new circuits will be created over the backup link. Existing LLC2 circuits on the 
backup link remain active. Therefore, do not use the linger option if you do not want to terminate ade 


circuits on the backup peer. If a linger value of 0 is used, the backup peer stays active until it fails, despite 
the status of the primary peer. The positive side of the linger option is that it will greatly stabilize the DLSw 
peers during situations in which a link might be flapping. The steps and syntax for configuring a backup peer 
are as follows: 


Step 1. Configure a primary peer to the primary DLSw router. 


dlsw remote-peer 0 tcp primary_peers_ip_address 


Step 2. Configure a backup peer to a new DLSw router. 


dlsw remote-peer 0 tcp backup_peers_ip_address backup-peer 
primary_peers_ip_address linger timeout_in_minutes 


In Figure 13-35, the solo router has a primary peer to the falcon router and a backup peer to skywalker. The 
peers on falcon and skywalker are configured as promiscuous, so no remote peer statements are needed for 
DLSw routers to establish a peer connection with these routers. On the router solo, we have configured a 
backup peer to skywalker. The statement dlsw remote-peer O tcp 172.16.128.5 backup-peer 
172.16.128.1 linger 5 instructs the solo router to establish a new peer to the skywalker router if the peer to 
falcon fails. 


Figure 13-35. Backup and Promiscuous Peers 
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Example 13-34 shows the output of the show disw peer command on the solo router from the previous 
figure. Notice that the backup peer is in a disconnect state while the primary is up. 


Example 13-34 show disw peer Command Output on solo Router Reveals Backup 
Peer Status 


solo#show dlsw peer 


Peers: state pkts_rx pkts_tx ‘type drops ckts TCP uptime 
TCP 172.16. 123.1 CONNECT 1268 190 conf a 0 0 00221256 
TCP’ 172.26.128..5 DISCONN 0 0 conf 0 0 = = 


Total number of connected peers: 1 
Total number of connections: 1 


solo# 


When the primary peer fails, the backup peer to the skywalker router will become active, as in Example 13-35. 
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Example 13-35 show disw peer Command Output on solo Router Reveals Backup 
Peer Status 


solo#show dlsw peer 


Peers: state pkts.- ex pkts_tx type drops ckts TCP uptime 
TCP 1£72..16.128..5 CONNECT 2 4 conf 0 0 0 00300529 
TCP 172.162 128.1 DISCONN 0 0 conf 0 0 - - 


Total number of connected peers: 1 
Total number of connections: Hl 


solo# 


When the primary peer between the solo and falcon routers becomes active again, the solo router waits until 
after the linger timer expires—in this example, 5 minutes—until it disconnects the backup peer and 
reconnects the primary peer. 


DLSw+ Backup over DDR 


The other method of DLSw+ backup involves keeping the peer connection established during a link failure. 
For example, if you are using an ISDN link for backup, you might want to keep the peer active while the ISDN 
line dials and makes a connection. The time for link such as this to converge can exceed the DLSw+ keepalive 
timers and force the peer down. The DLSw+ keepalives operate on TCP port 2065, which also makes it hard 
to control significant traffic with ACLs because data and keepalives use the same TCP port number. The no 
keepalive argument also keeps an ISDN link from dialing because of this type of traffic. Whenever setting 
the keepalive to 0, DLSw+ cannot tell whether the peer is still active based on keepalives. Therefore, it never 
tears down the peer based on missed keepalives. By adding a timeout value, the peer automatically is 
disconnected if no data has been received from a peer for the length of the timeout value. 


To configure DLSw+ to operate in environments like this, you can control the timeout values and keepalives 
of DLSw+. To configure this form of backup, follow this two-step process: 


Step 1. Use the keywords keepalive 0 on the local peer for both routers. 


Step 2. Assign a timeout value to the remote-peer statement on both routers. 


In Figure 13-36, the solo router has a DLSw+ TCP peer and an ISDN backup connection to the falcon router. 


Figure 13-36. Backup Peers over DDR 
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disw local-peer peer-id 172.16.128.9 keepalive 0 
disw remote-peer 0 tcp 172.16.128.1 timeout 300 


To keep the peer active while ISDN converges, set the keepalive to 0 and the timeout value to 5 minutes, or 
300 seconds. Example 13-36 illustrates the peer from solo to the falcon router remaining active during 
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convergence, while |P connectivity temporary doesn't exist. 


Example 13-36 DLSw+ Peer Remaining Active, While No IP Connectivity Exists 


solo#show dlsw peer 
Peers: state pkts_+x pkts_tx type drops ckts TCP uptime 


TCP: LIA 6. U8 ed CONNECT 14 2 €on£ 0 0 O VOSOL EST 


Total number of connected peers: 1 
Total number of connections: 1 


solo#tping 172.16.128.1 


Type escape sequence to abort. 

Sending 5, 100-byte ICMP Echos to 172.16.128.1, timeout is 2 seconds: 
Success rate is 0 percent (0/5) 

solo# 


DLSw+ Border Peers, Peer Groups, and Demand Peers 


Border peers and peer groups provide an effective way to scale DLSw networks that require any-to-any 
reachability and to control explorers. A DLSw router that requires any-to-any reachability would need a 
remote-peer statement to every router that it has a connection to. For example, Figure 13-37 illustrates a 
common network. 


Figure 13-37. DLSw Full Reachability 
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Only two workstations are illustrated in the figure, but they represent workstations that would reside on all 
the LAN segments of the access routers. For the workstations on the access routers to reach any workstations 
on any other access router, multiple remote peers statements are needed. 


Figure 13-38 represents all of the remote-peer statements that would be needed for any-to-any reachability 
to take place. 
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Figure 13-38. TCP Peers Required in a Fully Meshed Network 
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In this small network, you would have to configure 42 remote-peer statements. You easily can see how this 
type of network doesn't scale well. Besides, the amount of configuration associated with this type of network 
is the amount of explorer traffic traveling from peer to peer, which is more harmful than some extra 
keystrokes. 


Cisco DLSw+ supports the concept of peer groups and border peers and peer-on-demand. A peer group is a 
group of routers with one or more members designated as a border peer. The border peer's role is to forward 
explorers for routers in the peer group. When the border peer receives an explorer, it checks its local, remote, 
and group cache before forwarding the explorer to other routers. When the border peer checks its cache, if it 
gets a hit in its local cache, it does not forward the explorer to other routers. The remote cache contains 
information on reachability within the peer group. If the border peer gets a hit on this type of cache, it 
forwards the explorer only to routers in the same group. The group cache contains information about the 
other peer groups to which the border peer does not belong. When the border peer gets a hit in this cache, it 
forwards the explorer only to border peers. 


Figure 13-39 illustrates how the network would look if you divided it into two peer groups. Each peer group 
must have one border router to handle the proper forwarding of explorers for that group. The border peers 
also must have a peer between them. 


Figure 13-39. DLSw Border Peers and Peer Groups 
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To configure border peers and peer groups, use the following process: 


Step 1. Divide the network into peer groups. 


Step 2. Configure the peer group so that there is a single peer from all the routers to one peer within 
that group. This router with all the peers will be configured as the border peer. To configure a peer 


group, use the keyword group x on the local-peer statement. To configure a peer as a border peer, 
use the keyword border on the local-peer statement. 


Step 3. Configure a DLSw peer between border peers. 


Step 4. Optional: Configure DLSw peer-on-demand. For any-to-any reachability, such as with a 
NetBIOS or APPN applications, you must configure DLSw peer-on-demand. The peer-on-demand will 
allow a demand peer to be created between end stations that do not have a static peer configured 
between them. A demand peer is formed when a router in a peer group requests services from 


another router either in the group or external to it. To configure peer-on-demand, use the following 
syntax: 


dlsw peer-on-demand-defaults [tcp 25-2000] 


The command disw peer-on-demand allows for a peer to be created "on demand," or a demand peer. Do 
not confuse demand peers with dynamic peers—these two are different types of peers. The default values for 
the demand peer can be changed with the following global configuration command: 


Router (config) #dlsw peer-—on-demand-defaults [fst] [bytes-netbios-out bytes-—list-—name] 
[cost 1-5] [dest-mac destination_mac_address] [dmac-output-list access—list-—number] 
[host—netbios-out host-list-name] [keepalive seconds] [1f largest_frame_516-11407] 
[lsap-output-list list] [port-list port-list-—number] [priority] [tcp-queue-max size] 


When configuring border peers and peer groups, keep the following rules in mind: 
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In a single group, every member peer must peer to every border peer in its group. 

All border peers in a group must peer to each other. 

All border peers within a group must peer to every border peer in the other peer groups. 

Border peers forward explorers to all member peers in their group, all border peers in their group, and 
one border peer in every other group. 


In Figure 13-39, we have assigned IP addresses to routers and divided them into two peer groups. The west 


router will serve as the border peer for group 1, while the east router will serve as the border peer for group 
2. Example 13-37 lists the DLSw configuration of the routers in Figure 13-39. 


Example 13-37 Configuring Border Peers and Peer Groups 


Configuration of the west router: 


dlsw local-peer peer-id 172.16.128.1 group 1 border promiscuous 

dlsw remote-peer 0 tcp 172.16.128.5 

! 

! 

Configurations of the routers in group 1, such as the california router: 


dlsw local-peer peer-id 172.16.128.9 group 1 promiscuous 
dlsw remote-peer 0 tcp 172.16.128.1 

dlsw peer-on-demand-defaults tcp-queue-max 50 

! 

Configuration of the east router: 


disw local-peer peer-id 172.16.128.5 group 2 border promiscuous 

disw remote-peer 0 tcp 172.16.128.1 

! 

! 

Configurations of the routers in group 2, such as the new_york router: 
dlsw local-peer peer-id 172.16.128.13 group 2 promiscuous 

dlsw remote-peer 0 tcp 172.16.128.5 


dlsw peer-on-demand-defaults tcp-queue-max 50 
! 


Controlling DLSw+ Explorers with Ring Lists, Bridge Group Lists, and Port Lists 


Because you can configure only a single local peer on a router, this makes it difficult to control explorers 
among peers. A ring list allows you to specify which virtual rings or bridge groups will receive explorers from a 
specific remote peer. 


For example, in Figure 13-40, the yoda router has two Ethernet interfaces. One Ethernet interface, EO, is in 
bridge group 1; the other interface, E1, is in bridge group 2. 


Figure 13-40. DLSw Bridge Group Lists 
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In this model, you want to control DLSw+ so that explorers from the router ben will be forwarded only to the 
EO interface, or bridge group 1. Explorers from the router luke should be forwarded only to the E1 interface 
on the yoda router. To accomplish this type of configuration, DLSw+ supports the use of ring and port lists. 
To create a ring or port list, use the following procedure: 


luke 
LB20-IP=172.16.128.9/30 


Step 1. Separate the Token Ring and Ethernet bridging domains. For Ethernet networks, separate the 
bridging domains by placing Ethernet segments in different bridge groups. For example, EO will be in 
bridge group 1, and E1 will be in bridge group 2. In this example, you also need to add the commands 
bridge 1 protocol ieee and bridge 2 protocol ieee. For every bridge group, you will need to add 
that bridge group to DLSw+. In the previous example, you would need two commands to accomplish 
this—dlsw bridge-group 1 and disw bridge-group 2. 


For Token Ring networks, you would create separate virtual rings and source-route bridge each Token 
Ring interface to the various virtual rings. For example, Token Ring 0 would have the command 
source-bridge 10 1 100 to source-route bridge the interface to virtual ring 100. The other interface 
would be source-route bridged to another virtual ring. 


Step 2. Create a ring list. For Token Ring networks, create a ring list with the following global 
command: 


Router (config) #dlsw ring-list list_number_1-255 rings virtual-ring(s) 


For Ethernet networks, create a ring list with the following global command: 


Router (config) #dlsw bgroup-list list_number_1-255 bgroups 
bridge_group_number (s) 


Step 3. Call the ring list on the DLSw+ remote-peer statement. For example, if you use the 
command disw bgroup-list 1 bgroups 1 to create a ring list for Ethernet, you could call this list on 
the remote peer statement with the command disw remote-peer 1 tcp ip address. 


In Figure 13-41, we created two bridge groups on the router yoda. Each bridge group then is added to a 
DLSw bgroup list. The peer to the router ben will call bgroup list 1, and the peer to the router luke will call 
bgroup list 2. 


Figure 13-41. DLSw+ Bridge Group Lists Example 
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Explorers from luke will be forwarded only to the E1 interface on the router yoda. Explorers from the router 
ben will be forwarded only to the EO interface on the yoda router. Example 13-38 lists the configuration of the 


yoda router. 


Example 13-38 Configuration of the yoda Router 


hostname yoda 
! 
<<<text omitted>>> 
! 
dlsw local-peer peer-id 172.16.128.1 
dlsw bgroup-list 1 bgroups 1 
dlsw bgroup-list 2 bgroups 2 
dlisw remote-peer 1 tcp 172.16.128.5 
dlisw remote-peer 2 tcp 172.16.128.9 
dlsw bridge-group 1 
dlsw bridge-group 2 
! 
interface Loopback20 
ip address 172.16.128.1 255.255.255.252 
no ip directed-broadcast 
! 
interface Ethernet0 
no ip address 
no ip directed-broadcast 
media-type 10BaseT 
bridge-group 1 
! 
interface Ethernet1 
no ip address 
no ip directed-broadcast 
media-type 10BaseT 
bridge-group 2 
! 
<<<text omitted>>> 
! 
bridge 1 protocol ieee 
bridge 2 protocol ieee 


A port list might be used to map traffic on a local interface, either a Token Ring or a serial interface, to a 
remote peer. The syntax to accomplish this is as follows: 
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Router (config) #dlsw port-list list_number_1-255 [token-ring | serial] 
interface_number 


The port list is called in the same manner as the ring list or bridge list, on the remote-peer statement. 


DLSw+ Dynamic Peers 


A dynamic peer is yet another type of DLSw peer. A dynamic peer is a peer that becomes active only when 
certain criteria are met, such as MAC address or SAP type. To configure a dynamic peer, use the keyword 
dynamic on the remote peer statement. The inactivity timer also should be set when creating a dynamic 
peer. A dynamic peer will stay active 10 minutes after the last circuit has disconnected from the peer. When 
you create a dynamic peer, the router automatically adds a timeout value and disables keepalives. This is for 
the same reasons mentioned in the previous section on configuring backup over DDR. 


If you are using promiscuous peers with dynamic peers, be sure to modify the default values of the 
promiscuous peers to disable the keepalives. This can be done with the dlsw prom-peer-defaults 
command, as mentioned previously. 


In Figure 13-42, the solo router has a dynamic peer configured to skywalker. The remote-peer statement 
instructs the peer to be dynamic and to become active only when the output SAP filter 201 is met. The peer 
will remain active for 5 minutes after the last circuit has disconnected. The router inserts the keepalive 0 and 
timeout 90 on the remote peer statement automatically. The SAP filter in this example is access list 201, 
which permits only SAP OxFOFO, the NetBIOS SAP. We will discuss SAP filters more in the next section. 


Figure 13-42. DLSw Dynamic Peer 
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Example 13-39 lists the configuration of the solo router, with the dynamic peer configured to skywalker. 


Example 13-39 Configuration of the solo Router 


hostname solo 

! 

<<<text omitted>>> 
! 


disw local-peer peer-id 172.16.128.9 


dlisw bridge-group 1 
! 
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interface Loopback20 

ip address 172.16.128.9 255.255.255.252 
no ip directed-broadcast 

! 
interface Ethernet0 

ip address 172.16.6.1 255.255.255.0 
no ip directed-broadcast 
bridge-group 1 

! 
<<<text omitted>>> 

! 


bridge 1 protocol ieee 


NOTE 


Do not confuse dynamic peers with promiscuous or demand peers. This can be hard to do 
because all of these peer types are dynamic in some form. 


Configuring DLSw+ Reachability with the icanreach Command 


During the DLSw+ capabilities exchange, routers also exchange what resources they can reach in the control 
vectors. This is information that can be statically configured on the router. By configuring what SAP, MAC 
address, and NetBIOS names the router can reach, it can greatly reduce the number of explorers sent to 
remote peers. Along with the resources that the router can reach, you can configure the SAP values that the 
router cannot reach. If a router has a static entry defined by the icannotreach command, it also reports that 
to its peers. The peer keeps track of what resources it cannot reach and avoids sending explorers to those 
peers. To configure DLSW+ reachability, use the following commands: 


Router (config) #dlsw icanreach [mac-address | saps | netbios-—name] 
Router (config) #dlsw icannotreach [saps] <0-FE> Even SAP Value (hex) 


When using the icanreach saps command, be careful because it will deny all other SAPs. In other words, 
there is an implicit "deny all SAPs" that follow the use of this command. It is best to use the icannotreach 
command to deny explicit SAPs. 


Use the mac-exclusive parameters and the netbios-exclusive arguments to advertise reachability to a 
single address or host. These commands must be used with another statement, dlsw icanreach mac 
address or netbios name: 


Router (config) #dlsw icanreach [mac-exclusive | netbios-exclusive] 


In Figure 13-43, we have configured DLSw reachability on the falcon router. In this example, the falcon router 
will advertise that it can reach only a single MAC address, 3745.1000.1010. Example 13-40 lists the 
configuration needed on the falcon router to accomplish this. 


Figure 13-43. DLSw Reachablity 
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Example 13-40 Configuration DLSw+ Reachability on the falcon Router 


! 
dlisw local-peer peer-id 172.16.128.5 promiscuous 

dlsw icanreach mac-exclusive 

dlsw icanreach mac-address 3745.1000.1010 mask ffff.ffff.fffFf 
dlisw bridge-group 1 

! 


By viewing the DLSw reachability on the solo router in Example 13-41, you can see that the MAC address is 
the only one being advertised by the falcon router. The status is unconfirmed because it is a static entry. 


Example 13-41 The DLSw Reachability on the solo Router 


solo#show dlsw reach 
DLSw Local MAC address reachability cache list 


Mac Addr status Loc port rif 

0000.613c.dc82 FOUND ,OCAL TBridge-001 ==no: £it== 
0006.3acf.7aa6é FOUND ,OCAL TBridge-001 ==no rLr== 
0007.78la.e7a9 FOUND ,OCAL TBridge-001 ==no rir== 


DLSw Remote MAC address reachability cache list 
Mac Addr status Loe. peer 


DLSw Local NetBIOS Name reachability cache list 
NetBIOS Name status Loc. port rit 
R2-D2 FOUND LOCAL TBridge-001 ==no ‘rit== 


DLSw Remote NetBIOS Name reachability cache list 
NetBIOS Name status Loe. peer 


To view details about what addresses and SAP the router now can reach, use the show dlIisw capabilities 
command. Example 13-42 lists the capabilities on the solo router. Notice that one MAC address is reported, 


and the max-exclusive column now is set to yes. 


Example 13-42 The DLSw+ Capabilities of the solo Router 


solo#show dlsw capabilities 

DLSw: Capabilities for peer 172.16.128.5 (2065) 
vendor id (OUT) > *00C" (“eitsce) 
version number f.2 
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release number : 0 


init pacing window 2 20 
unsupported saps : none 
num of tcp sessions : 2 
loop prevent support 2 0 
icanreach netbios-excl. : no 
reachable netbios names : none 
V2 multicast capable : yes 
DLSw multicast address : none 
cisco version number 2 i 
peer group number : 0 
peer cluster support : no 
border peer capable : no 
peer cost : 3 
biu-segment configured : no 
UDP Unicast support : yes 
Fast-switched HPR supp. : no 
NetBIOS Namecache length : 15 
local-ack configured : yes 
priority configured : no 
cisco RSVP support : no 
configured ip address Y LIZ«P62128'.5 
peer type 2 prom 


version string : 
Cisco Internetwork Operating System Software 
IOS (tm) 2500 Software (C2500-JS-L), Version 12.1(2)T, RELEASE SOFTWARE (fcl) 
Copyright (c) 1986-2000 by cisco Systems, Inc. 
Compiled Tue 16-May-00 15:28 by ccai 


solo# 


You also can use the disw reachability command to help you test DLSw networks. By configuring a router 
with a disw icanreach dummyname, you can easily tell whether your DLSw configuration is working by 
examining the reachability of its peer routers. 
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Filtering Traffic in Bridged Environments 


In this section, we discuss the various methods for filtering in a bridged environment. If you 
are not familiar with access lists you might want to skip ahead to Chapter 14, "Understanding 


IP Access Lists." Even though that chapter deals strictly with IP access lists, the concepts, 
rules, and tips apply to all access lists. 


Filtering for bridges and data-link switches occurs at the data link layer. Cisco provides three 
primary types of filters for the data link layer: 


e Service access point (SAP) filters 
e MAC filters 
e NetBIOS name filters 


Filtering SAPs 


For SNAP encapsulated frames, an access list filters based on the 2-byte TYPE field given 
after the DSAP/SAP/OUI fields of the frame. For |EEE 802.2 frames, access lists filter on the 
DSAP/SSAP fields. The syntax for an access list to filter based on SAPs is as follows: 


Router (config) #access-list [200-299] [deny | permit] [0Ox0-OxFFFF] <0Ox0-OxFFFF> 


The first value is the protocol type code, and the second value is the protocol type-code 
mask. The valid range for access lists that filter based on the protocol type field or SAP is 200 
to 299. The access list is entered in hexadecimal format, where the hexadecimal address is 
followed by a wildcard mask. The wildcard mask is applied to the address, where a 1 bit 
means "don't care" and a 0 bit is a "care" bit. An all O's masks means that you must match 
the address bit for bit, to yield a TRUE result for the access list. For more information on 
access-list formats and the wildcard mask, skip ahead to Chapter 14. 


SNA SAPs 


SNA uses multiple SAPs. Fortunately, they can be filtered with a single SAP of OxODOD. The 
primary SAPs that SNA uses are as follows: 


0x04 = IBM SNA path control (individual) 
0x05 = IBM SNA path control (group) 
0x08 = IBM SNA 3270 terminals 

0x09 = IBM SNA 

0x0c = IBM SNA 3270 terminals 


All five SAPs can be filtered with the single "wildcard" SAP of OxODOD, which will include all 
SAP types. The access list to allow only SNA SAPs would resemble the following: 
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Router (config) #access—list 200 permit 0x0d0d 0x0000 
NetBIOS SAPs 
NetBIOS traffic uses the following SAP values: 

OxfO0 = IBM NetBIOS commands 

Oxfl = IBM NetBIOS responses 


The hexadecimal address and the appropriate wildcard mask for these two SAPS is OxfOfO 
0x0101. The access list to allow only NetBIOS SAPs resembles the following: 


Router (config) #access—-list 200 permit Oxf0Of0 0x0101 


Filtering simply the NetBIOS commands is sufficient to control all NetBios traffic as well. 


Router (config) #access-—list 200 permit OxFOFO 


IPX SAPs 

IPX using 802.2 encapsulation uses the following SAP value: 
OxeO = Novell NetWare 

The access list to allow only IPX SAPs resembles the following: 

Router (config) #access-list 200 permit Oxe0e0 0x0000 

Or, simply: 

Router (config) #access—list 200 permit Oxe0e0 

Filtering and Blocking all SAPs 


All access lists, the 200 series included, have an implicit deny any at the end of the list. The 
implicit deny does not show up in the configuration when it is displayed. 


The access list to allow all SAPs resembles the following: 


Router (config) #access—list 200 permit 0x0000 Oxffff 


Conversely, the access list to deny all SAPs would look like the following: 


Router (config) #access—list 200 deny 0x0000 Oxffff 


CAUTION 
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Extreme care should be used whenever integrating IPX networks with DLSw. By 
default, Cisco routers will bridge I PX traffic. That means that DLSw also will pass 
IPX packets, unless ipx routing is enabled on the DLSw router. However, a 
router might be configured only for IP serving a primary DLSw peer for the SNA 
network, or an "SNA/DLSw peering router." If |PX also is running on the 
backbone of this network, "SNA peering routing" doesn't carry any | PX traffic; 
IPX routing isn't configured for this router. If the SNA/DLSw peering router has 
any interfaces that receive | PX traffic, it will not route |PX, but it will bridge it 
across all the DLSw peers. Soon IPX networks will be showing up all over, and 
the serial links can come to a screeching halt, all because they are bridging an 
entire |PX domain. Fortunately, this can be easily corrected by enabling IPX on 
the SNA/DLSw peering router or by filtering the IPX SAP, if the proper Cisco |OS 
Software isn't available. 


MAC Filtering 


The access list range of 700 allows filtering based on MAC address. The syntax for a 700 
series list is as follows: 


Router (config) #access-list [700-799] [deny | permit] [MAC_address] 
<MAC_address_mask> 


Most often, this access list is entered with just a single MAC address. This is primarily because 
MAC addresses are not inclusive, unless you define them yourself. For example, to configure 
an access list to allow only MAC address 0060.5cf3.5da4, you would use the following syntax: 


access-list 701 permit 0060.5cf3.5da4 

NetBIOS Name Filtering 

To filter NetBIOS based on the name, use the following syntax: 

Router (config)#netbios access-list host access_list_name [deny | permit] pattern 
For example, to filter a NetBIOS name of HARLY, you would use the following syntax: 

netbios access-list host denyharly deny HARLY 

The following should be kept in mind when using NetBIOS access lists: 


e Access-list arguments are case-sensitive. Most NetBIOS names are in uppercase. 

e The station names included in the access lists are compared with the source name 
field for NetBIOS commands 00 and 01 (ADD_GROUP_NAME_QUERY and ADD _ 
NAME_QUERY), as well as the destination name field for NETBIOS commands 08, 0a, 
and Oe (DATAGRAM, NAME_QUERY, and NAME_RECOGNI ZED. 


Practical Example: Filtering in a Bridged Environment 
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All of these access lists can be applied in a number of ways. All of the aforementioned filters 
mentioned can be applied to the physical interface, a DLSw peer, or a source-route bridge. 


The syntax needed to apply these filters to a source-route bridge or DLSw peer is listed in the 
previous sections. 


Figure 13-44 presents a DLSw network with routers solo and chewbacca. You want to apply 


an LSAP filter so that only SNA SAPs will cross the DLSw link between the two routers. To 


accomplish this, configure an access list in the 200s range, permitting SAP Ox0d0d, like the 
following: 


Figure 13-44. DLSw LSAP Filters 
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Attach the filter to the remote-peer statement of each router, using the Isap-output-list 
argument. 
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Lab 26: Transparent Bridging, Remote Source-Route Bridging, LSAP 
Filtering—Part | 


Practical Scenario 


Nonroutable protocols such as NetBIOS and SNA are still much alive in the modern internetwork. 
There are many ways to transport these protocols across the network. This lab gives you practice 
in performing transparent bridging and RSRB, setting root, and LSAP filters. 


Lab Exercise 


An underground network of crime fighters exists in secret locations from the valleys of California 
to the hills of northern Wisconsin. The specific locations are secret, and the routers are identified 
only by code names, such as trashman and beerbelly. The crime fighters want to link their 
existing networks, to utilize the super computer H.O.O.V.E.R. Their supercomputers, H.O.O.V.E.R. 
and H.O.0.V.E.R.2, are SNA mainframes, so the remote sites must be bridged to the crime 
fighters' headquarters. Your task is to configure a bridged and routed network, using the following 
design guidelines: 


e Configure an 1P network, as depicted in Figure 13-45, using EIGRP as the routing protocol 
and 2001 as the Autonomous System ID. 


Figure 13-45. Crime Fighters Network 
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e Configure the Frame Relay network as depicted in Figure 13-45. Do not configure DLSw in 
this lab. 

e Configure the network so that the routers lone_rhino and trashman can transport SNA to 
the HQ site or the wolf router. 

e Configure the router beerbelly so that it has SNA access to the mainframe H.O.0O.V.E.R.2. 
The H.0.0.V.E.R.2 mainframe requires a RIF. Ensure that your configuration supports this. 

e Do not allow NetBIOS traffic from Ring 2 on the beerbelly router to Ring 1 on the wolf 
router. 

e Set the wolf router to be root of the transparent bridging domain. 

e A "double secret" workstation is located off the Token Ring interface on the beerbelly 
router. Because this workstation is so secret, you need to configure a static RIF to it. 
Configure the RIF as follows: Secret Workstation MAC = 0101.0027.0081; RING2- 

BRI DGE9-RING50-BRIDGE5-RING52-BRIDGE13-RING7. 


Lab Objectives 


e Configure the crime fighters network as depicted in Figure 13-45. Configure IP as denoted 
in the figure. Use EIGRP as the routing protocol, with an Autonomous System ID of 2001. 

e Use Frame Relay as the data link protocol on the WAN. Configure a Frame Relay multipoint 
network between the wolf, lone_rhino, and trashman routers. Configure a Frame Relay 
point-to-point network between the wolf and beerbelly routers. 

e Configure transparent bridging on the Ethernet interfaces of the lone_rhino, trashman, and 
wolf routers. Bridge these routers over the Frame Relay network. 

e Configure remote source-route bridging between the Token Ring interfaces of the beerbelly 
and wolf routers. 

e Configure source-route bridging so that NetBIOS traffic will not be forwarded by the 
remote source-route bridge. 

e Configure a static RIF on the beerbelly router with the following guidelines: MAC = 
0101.0027.0081; RING2-BRIDGE9-RING50-BRIDGE5-RING52-BRIDGE13-RING7. 


Equipment Needed 


e Five Cisco routers. Four will be connected through V.35 back-to-back cables or in a similar 
manner to a Frame Relay switch. 

e Five LANs segments, provided by hubs or switches. One router will need a Token Ring 
interface and an Ethernet interface. One other router will need to be Token Ring as well. 


Physical Layout and Prestaging 


e Connect the hubs and serial cables to the routers as shown in Figure 13-45. 
e A Frame Relay switch with three PVCs also is required. Example 13-43 lists the Frame 
Relay configuration used in this lab. 


Example 13-43 Frame Relay Switch Configuration 


hostname frame_switch 

! 

interface Serial0 

no ip address 

encapsulation frame-relay 

no fair-queue 

clockrate 148000 

frame-relay intf-type dce 

frame-relay route 111 interface Seriall 110 
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interface Seriall 

no ip address 

encapsulation frame-relay 

clockrate 148000 

frame-relay intf-type dce 

frame-relay route 110 interface SerialO 111 
frame-relay route 130 interface Serial3 131 
frame-relay route 180 interface Serial5 181 
! 

<<<text omitted>>> 

! 

interface Serial3 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay intf-type dce 

frame-relay route 131 interface Seriall 130 
! 

<<<text omitted>>> 

! 
interface Serial5 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay intf-type dce 

frame-relay route 181 interface Seriall 180 
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Lab 26: Transparent Bridging, Remote Source-Route Bridging, 
LSAP Filtering—Part Il 


Lab Walkthrough 


Configure the Frame Relay switch and attach the four routers in a back-to-back manner to the 
Frame switch. Use V.35 cables or CSU/DSUs with crossover cables to connect the routers. 
Create the three Ethernet LANs and two Token Ring LANs by the use of switches or hubs/ 
MAUs, as illustrated in Figure 13-45. 


When the physical connections are complete, assign IP addresses to all LAN and WAN 
interfaces, as depicted in Chapter 11, "Hybrid: Enhanced Interior Gateway Routing Protocol 


(EGIRP)." 


Example 13-44 Frame Relay and EI GRP Configurations of wolf, 
lone_rhino, and beerbelly 


hostname wolf 

! 

<<<text omitted>>> 

! 

interface Serial0 

no ip address 

no ip directed—-broadcast 
encapsulation frame-relay 

no ip mroute-cache 

logging event subif-link-status 
logging event dlci-status-—change 
frame-relay lmi-type cisco 

! 

interface Serial0.1 multipoint 

ip address 172.16.1.1 255.255.255.0 
no ip directed—-broadcast 


interface Serial0.2 point-to-point 
ip address 172.16.2.1 255.255.255.0 
no ip directed-broadcast 


! 
<<<text omitted>>> 


passive-interface Ethernet0 
network 172.16.0.0 

no auto-summary 

! 
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hostname lone_rhino 

! 

<<<text omitted>>> 

! 

interface Serial0d 

ip address 172.16.1.5 255.255.255.0 
encapsulation frame-relay 


! 
<<<text omitted>>> 
! 


router eigrp 20010 
network 172.16.0.0 


no auto-summary 
! 


hostname trashman 

! 

<<<text omitted>>> 

! 

interface Serial0 

ip address 172.16.1.6 255.255.255.0 
no ip directed-broadcast 
encapsulation frame-relay 

no ip mroute-cache 


frame-relay lmi-type cisco 
! 

<<<text omitted>>> 

! 


router eigrp 20010 
network 172.16.0.0 


no auto-summary 
! 


hostname beerbelly 

! 

<<<text omitted>>> 

! 

interface Serial0 

ip address 172.16.2.2 255.255.255.0 
encapsulation frame-relay 
frame-relay interface-dlci 181 
frame-relay lmi-type cisco 

! 

<<<text omitted>>> 

! 

router eigrp 2001 

network 172.16.0.0 

no auto-summary 

! 
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After the Frame Relay network is configured and you have full |P reachability, you can begin to 
configure the bridging environment. 


Your first task is to configure transparent bridging between the Ethernet segments of the wolf, 
lone_rhino, and trashman routers. You also must set the root of the Spanning Tree to be the 
wolf router. To accomplish this, you can follow this three-step configuration task list: 


Step 1. Configure a bridge number and Spanning Tree for that bridge. 
Step 2. Configure the interfaces to be a part of that bridge group. 


Step 3. Configure a root bridge. 


Beginning with Step 1, use the router command bridge-group 1 protocol ieee to create the 
bridge group on all the routers that you want to configure transparent bridging on. Step 2 
involves assigning the physical or logical interfaces to the bridge group that you created. This 
is done with the interface command bridge-group 1. On Frame Relay multipoint interfaces, 
such as the SO.1 interface on wolf and the sO interfaces on lone_rhino and trashman, you 
need to configure a frame-relay map bridge statement. Example 13-45 demonstrates Steps 
1 and 2 being performed on the wolf router. 


Example 13-45 Transparent Bridging Configuration on the wolf Router 


wolf (config) #bhridge 1 protocol ieee 

wolf (config) #interface ethernet 0 

wolf (config-if) #bridge-group 1 

wolf (config) #interface serial 0.1 

wolf (config-subif) #bridge-group 1 

wolf (config-subif) #frame-relay map bridge 110 broadcast 
wolf (config-subif) #frame-relay map bridge 130 broadcast 
wolf (config-subif) # 


Example 13-46 demonstrates the transparent bridging configuration on the lone_rhino router. 


Example 13-46 Transparent Bridging Configuration on the lone_ rhino 
Router 


lone_rhino(config) #bridge 1 protocol ieee 
lone_rhino(config) #interface e0 

lone_rhino(config-if) #bridge-group 1 
lone_rhino(config-if) #exit 

lone_rhino(config) #interface sO 

lone_rhino(config-if) #bridge-group 1 

lone_rhino(config-if) #frame-relay map bridge 111 broadcast 


The configuration for transparent bridging on the trashman is nearly identical to the 
configuration on the lone_rhino router. The frame-relay map statement for the trashman 
router would read frame-relay map bridge 131 broadcast. At this point, transparent 
bridging is working. You can determine the status of the bridge with the show bridge 
command, as shown in Example 13-47. 


Example 13-47 Viewing the Status of the Transparent Bridge sis 


trashman#show bridge 


Total of 300 station blocks, 295 free 
Codes: P - permanent, S - self 


Bridge Group 1: 


Address Action Interface Age RX count TX count 
0060.5cf3.5e65 forward Etherneto 0) 44 0 
0050.5475.elad forward Serial0O 0 10 ) 
0000.8108.caae forward Serial0o 0 20 0 
0000.863c.3b41 forward Serial0O 3 2 0 
00e0.b05a.66e4 forward Serial0O 3 il 0 


trashman# 


The bridge should start displaying MAC address and should be forwarding out the serial and 
Ethernet interfaces. If you are not seeing this, ensure that the Frame Relay and Ethernet 
interfaces are all in the same bridge group. Also be sure that you have frame-relay map 
statements for the bridge. 


Step 3 calls for configuration of the root of Spanning Tree to be the wolf router. This model 
might not be the same for yours; the root of Spanning Tree is the trashman router. To check 
which router is the current root, use the show spanning-tree command. Example 13-48 
demonstrates this command on the trashman router. Notice that trashman is the current root 
for STP. 


Example 13-48 Viewing STP on the trashman Router 


trashman#show spanning-tree 


Bridge group 1 is executing the IEEE compatible Spanning Tree protocol 
Bridge Identifier has priority 32768, address 0060.5cf3.5da4 
Configured hello time 2, max age 20, forward delay 15 


Port Number size is 9 

Topology change flag not set, detected flag not set 

Times: hold 1, topology change 35, notification 2 
hello 2, max age 20, forward delay 15 

Timers: hello 1, topology change 0, notification 0 

bridge aging time 300 


Port 2 (Ethernet0O) of Bridge group 1 is forwarding 
Port path cost 100, Port priority 128 
Designated root has priority 32768, address 0060.5cf3.5da4 
Designated bridge has priority 32768, address 0060.5cf3.5da4 
Designated port is 2, path cost 0 
Timers: message age 0, forward delay 0, hold 0 
BPDU: sent 0, received 0 


Port 6 (Serial0O Frame Relay) of Bridge group 1 is forwarding 
Port path cost 647, Port priority 128 
Designated root has priority 32768, address 0060.5cf3.5da4 
Designated bridge has priority 32768, address 0060.5cf3.5da4 
Designated port is 6, path cost 0 
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Timers: message age 0, forward delay 0, hold 0 
BPDU: sent 0, received 0 


trashman# 


To change the root so that it resides on the wolf router, use the following global command on 
the wolf router: 


wolf (config) #bridge 1 priority 100 


By viewing STP on the trashman router as demonstrated in Example 13-49, you can see that 
the root is now the wolf router and that the priority has been changed to 100. 


Example 13-49 Viewing STP on the trashman Router 


trashman#show spanning-tree 

Bridge group 1 is executing the IEEE compatible Spanning Tree protocol 
Bridge Identifier has priority 32768, address 0060.5cf3.5da4 
Configured hello time 2, max age 20, forward delay 15 
Gu P eee eb ese Eos ve recone be ee rescne4 
iScscl Se CES tem aU chart gi ocied oe CRM lc he i ape lcnia 
Port Number size is 9 
Topology change flag not set, detected flag not set 
Times: hold 1, topology change 35, notification 2 

hello 2, max age 20, forward delay 15 

Timers: hello 0, topology change 0, notification 0 
bridge aging time 300 


Port 2 (Ethernet0O) of Bridge group 1 is forwarding 
Port. path cost 100, Port priority 128 
Designated root has priority 100, address 00e0.1e58.e792 
Designated bridge has priority 32768, address 0060.5cf3.5da4 
Designated port is 2, path cost 647 
Timers: message age 0, forward delay 0, hold 0 
BPDU: sent 0, received 0 


Port 6 (Serial0O Frame Relay) of Bridge group 1 is forwarding 
Port path cost 647, Port priority 128 
Designated root has priority 100, address 00e0.1e58.e792 
Designated bridge has priority 100, address 00e0.1e58.e792 
Designated port is 12, path cost 0 
Timers: message age 2, forward delay 0, hold 0 
BPDU: sent 0, received 57 


trashman# 


The next portion of the lab involves configuring the beerbelly router so that its Token Ring 
network can have SNA access to the mainframe H.O.0.V.E.R.2 on the Token Ring network on 
the wolf router. The SNA application requires a RIF, so you must account for this in your 
configuration as well. To transport SNA across the WAN, you will use RSRB, primarily because 
you cannot use DLSw+ in the lab. 


Recalling the four-step process for configuring RSRB, you have the following: 


Step 1. Enable the use of the RIF, if required, with the router interface canines 


multiring all command. 


Step 2. Enable the virtual ring with the source-bridge ring-group virtual_ring 
command. 


Step 3. Configure SRB from the physical ring to the virtual ring. 


Step 4. Determine the encapsulation type to use, and configure RSRB. In this 
exercise, you will use TCP as the encapsulation type. 


To create a remote peer for each peer router and one for the local router with TCP as 
the encapsulation type, use the following global router command: 


source-bridge remote-peer virtual_ring tcp ip_address 
[lf largest_frame_size] [local-ack] 


Before you begin configuring RSRB, you should take the extra time to label a common virtual 
ring on the diagram and to configure the loopback address for the RSRB peers. Figure 13-46 is 
a new diagram of the network illustrating the loopback address/interfaces and the common 
virtual ring of 101. 


Figure 13-46. Crime Fighters Network 
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In this model, the H.O.0.V.E.R.2 mainframe requires a RIF field. Therefore, in Step 1, you 
must enable the RIF on all Token Ring interfaces with the interface command multiring all. 
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Step 2 calls for configuring a virtual ring. In this model, we have chosen to use a virtual ring 
of 101. The virtual ring is configured on the wolf and the beerbelly routers with the global 
command source-bridge ring-group 101. Step 3 involves configuring SRB on the Token 
Ring interfaces that you want to join to the RSRB group. The configuration for SRB on the 
beerbelly router resembles the following: 


beerbelly (config-if) #source-—bridge 2 1 101 


The source-bridge command on the wolf router resembles the following: 


wolf (config-if) #source-bridge 1 1 101 


Example 13-50 shows the source-route bridge configuration of beerbelly. 


Example 13-50 Configuration of beerbelly, up to This Point 


hostname beerbelly 
! 


<<<text omitted>>> 
! 


source-bridge ring-group 101 == *~_ virtual ring 

! 

interface Loopback20 === *_ Loopback for RSRB peers 
ip address 172.16.192.5 255.255.255.252 

! 

<<<text omitted>>> 

! 


interface TokenRingO 
ip address 172.16.3.1 255.255.255.0 
ring-speed 16 


Step 4 calls for configuring RSRB peers and the transport type. In this model, you are using 
TCP for the RSRB transport. Therefore, you need to configure one RSRB TCP peer on each 
local router pointing at itself and one RSRB TCP peer pointing at the other router—or, more 
specifically, the other router's loopback address. Example 13-51 illustrates the configuration of 
RSRB needed on the beerbelly and wolf routers. The RSRB remote-peer statements on 
beerbelly will match the remote-peer statement on the wolf router exactly. Remember that 
you always need a remote peer for the local router in RSRB configuration. 


Example 13-51 Configuration of the beerbelly Router 


! 
source-bridge ring-group 101 
source-bridge remote-peer 101 tcp 172.16.192.5 


source-bridge remote-peer 101 tcp 172.16.192.1 
! 


At this point, the RSRB configuration is operational. To determine the status of the RSRB, use 
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the command show source-bridge. Example 13-52 displays the status of the RSRB on the 
wolf router. If the RSRB has detected traffic, it should be in an "open" state. 


Example 13-52 Viewing the RSRB on the wolf Router 


wolf#show source—bridge 


Local Interfaces: receive transmit 
srn bn trn rps n max hops ont ont drops 
ToO 1 a Od. * b a p.. | 40 0 0 


Global RSRB Parameters: 
TCP Queue Length maximum: 100 


Ring Group 101: 
This: TCP peers 172.16.192.1 
Maximum output TCP queue length, per peer: 100 


Peers: state bg lv pkts rx pkts tx expil on drops. TCP 

TCP 172 16.192 . 1 = 3 ) 0 0 ) ) 

Rings: 

bie: 2. Bie: local ma: 4007.78la.e789 TokenRingO fwd: 0 

bhi 1 tne 2 remote mat 4000.30b1.270a TCP 172.16.192.5 fwd: 0 
Explorers: -------— Nc CoutpUE —===S== 

spanning all-rings total spanning all-rings total 

ToO 0 40 40 0) 0) ) 


Explorer fastswitching enabled 


Local switched: 40 flushed 0 max Bps 38400 
rings inputs bursts throttles output drops 
ToO 40 0) 0 ) 
wolf# 


When the RSRB is up and operational, apply the filter to it. In this model, you want to prevent 
the RSRB from transporting NetBIOS. To filter NetBIOS on the RSRB, you need to configure a 
SAP filter, denying SAP Oxf0. Because there is an implicit deny for all SAPs, you must add 
another line to override this. You then can apply the SAP filter to the RSRB with the command 
rsrb remote-peer Isap-output-list. Example 13-53 lists the relevant portions of the 
configuration from the wolf router. 


Example 13-53 Filtering SAP on a RSRB 


The final portion of this lab involves configuring a static RIF on the beerbelly router. The RIF 
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that you need to configure is the following: 


MAC = 0101.0027.0081; RING2-BRIDGE9-RING50-BRIDGE5-RING52-BRIDGE13-RING7 


Recall from the previous section that a static RIF is built from left to right. The first byte in our 
static RIF will be 0a30. 


The first two bits, from left to right again, equal 00. This sets the explorer type to be a specific 
routes explorer. You want to use this explorer type because this is a static RIF. The bit 3 is set 
to 0, and it is reserved. The next five bits set the length of the RIF in bytes. In this example, 
the RIF is 10 bytes, or Ox0a. The next bit, the D or direction bit, is set to 0, indicating that the 
RIF is read from left to right, or forward. The next three bits are set to 011, which sets the 
frame size to be 4472, the Cisco maximum. The last four bits are reserved. 


The RD fields, the next 4 bytes, break down rather easily: The next four bytes, 0029, 0325, 
0034d, and 0070, are the four 16-bit RD fields. The first three bits of each byte are the ring 
number in hexadecimal format. The last bit is the ring number in hexadecimal format. For the 
RIF in this example, you have the following: 


RING2 to BRIDGE9 = 0029 
RING50 to BRIDGE5 = 0325 
RING52 to BRIDGE13 = 034d 
RING7 to BRIDGEO = 0070 


A bridge of 0 tells the SRB to terminate the RIF and that no more bridges follow the ring. 
Example 13-54 demonstrates the configuration of the static RIF on the beerbelly router, 
followed by the show rif command. 


Example 13-54 Configuring and Viewing a Static RIF 


beerbelly#conft t 

Enter configuration commands, one per line. End with CNTL/Z. 
beerbelly (config) #rif 0101.0027.0081 0a30.0029.0325.034d.0070 to0 
beerbelly (config) #exit 


beerbelly#show rif 


Codes: * interface, - static, + remote 

Dst HW Addr Src HW Addr How Idle(min) Vlan Routing Information Field 
0000.30b1.270a N/A ToO im = 

beerbelly# 


Example 13-55 shows the complete configurations used in this lab. 


Example 13-55 Final Configuration Listings 


hostname wolf 
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! 
source-bridge ring-group 101 
source-bridge remote-peer 101 tcp 172.16.192.1 
source-bridge remote-peer 101 tcp 172.16.192.5 
rsrb remote-peer 101 tcp 172.16.192.5 lsap-output-list 201 
! 
interface Loopback20 
ip address 172.16.192.1 255.255.255.252 
no ip directed—-broadcast 
! 
interface Ethernet0 
ip address 172.16.55.1 255.255.255.0 
no ip directed—-broadcast 
media-type 10BaseT 
bridge-group 1 
! 
<<<text omitted>>> 
! 
interface Serial0 
no ip address 
no ip directed—-broadcast 
encapsulation frame-relay 
no ip mroute-cache 
logging event subif-link-status 
logging event dlci-status-—change 
frame-relay lmi-type cisco 
! 
interface Serial0O.1 multipoint 
ip address 172.16.1.1 255.255.255.0 
no ip directed—-broadcast 
no ip split—-horizon eigrp 2001 
frame-relay map bridge 130 broadcast 
frame-relay map bridge 110 broadcast 
frame-relay map ip 172.16.1.5 110 broadcast 
frame-relay map ip 172.16.1.6 130 broadcast 
bridge-group 1 
! 
interface Serial0.2 point-to-point 
ip address 172.16.2.1 255.255.255.0 
no ip directed—-broadcast 
frame-relay interface-dlci 180 
! 
<<<text omitted>>> 
! 
interface TokenRingO 
ip address 172.16.35.1 255.255.255.0 
no ip directed—-broadcast 
ring-speed 16 
multiring all 
source-bridge 1 1 101 
! 
router eigrp 2001 
passive-interface Ethernet0 
network 172.16.0.0 
no auto-summary 
! 
<<<text omitted>>> 
! 
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access-list 201 deny OxFOFO 0x0000 
access-list 201 permit 0x0000 OxFFFF 
! 

bridge 1 protocol ieee 

bridge 1 priority 100 


hostname lone_rhino 

! 

<<<text omitted>>> 

! 

interface Ethernet0O 

ip address 172.16.5.1 255.255.255.0 
bridge-group 1 

! 

interface Serial0 

ip address 172.16.1.5 255.255.255.0 
encapsulation frame-relay 
frame-relay map bridge 111 broadcast 
frame-relay map ip 172.16.1.6 111 broadcast 
frame-relay map ip 172.16.1.1 111 broadcast 
bridge-group 1 

! 

<<<text omitted>>> 

! 
router eigrp 2001 

network 172.16.0.0 

no auto-summary 

! 
<<<text omitted>>> 

! 


bridge 1 protocol ieee 


hostname trashman 

! 

<<<text omitted>>> 

! 

interface Ethernet0O 

ip address 172.16.6.1 255.255.255.0 
no ip directed-broadcast 
bridge-group 1 

! 

interface Serial0 

ip address 172.16.1.6 255.255.255.0 
no ip directed-broadcast 
encapsulation frame-relay 

no ip mroute-cache 

frame-relay map bridge 131 broadcast 
frame-relay map ip 172.16.1.5 131 broadcast 
frame-relay map ip 172.16.1.1 131 broadcast 
frame-relay lmi-type cisco 
bridge-group 1 

! 

<<<text omitted>>> 

! 
router eigrp 2001 

network 172.16.0.0 

no auto-summary 
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! 
<<<text omitted>>> 
! 


bridge 1 protocol ieee 


hostname beerbelly 
! 
! 
rif 0101.0027.0081 0A30.0029.0325.034D.0070 TokenRingO 
! 
<<<text omitted>>> 
! 
source-bridge ring-group 101 
source-bridge remote-peer 101 tcp 172.16.192.5 
source-bridge remote-peer 101 tcp 172.16.192.1 
rsrb remote-peer 101 tcp 172.16.192.1 lsap-output-list 201 
! 
interface Loopback20 
ip address 172.16.192.5 255.255.255.252 
! 
interface Serial0 
ip address 172.16.2.2 255.255.255.0 
encapsulation frame-relay 
frame-relay interface-dlici 181 
frame-relay lmi-type cisco 
! 
<<<text omitted>>> 
! 
interface TokenRingO 
ip address 172.16.3.1 255.255.255.0 
ring-speed 16 
multiring all 
source-bridge 2 1 101 
! 
<<<text omitted>>> 
! 
router eigrp 2001 
network 172.16.0.0 
no auto-summary 
! 
<<<text omitted>>> 
! 
access-list 201 deny OxFOFO 0x0000 
access-list 201 permit 0x0000 OxFFFF 
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Lab 27: DLSw+ TCP, LLC2, Promiscuous, Dynamic, and Backup Peer 
Configuration—Part | 


Practical Scenario 


DLSw+ provides an effective way, if not the best way, to transport legacy protocols over a TCP 
network. Advanced configuration of DLSw-+ can be used to control traffic and to provide enhanced 
backup capabilities. This lab gives you extensive practice in configuring multiple types of DLSw+ 
peers. In this lab, you will practice configuring DLSw+ TCP peers, LLC2 peers, promiscuous peers, 
backup peers, and dynamic peers. You also will control traffic with SAP filters and port lists. 


Lab Exercise 


Our original crime fighters are back in this exercise. They currently transport SNA and NetBIOS 
across a Frame Relay network, using transparent bridging and remote source-route bridging. The 
crime fighters have two supercomputers, the H.O.O.V.E.R. and H.O.O.V.E.R.2. They would like to 
provide access to these computers by DLSw. Your task is to configure DLSw+ with the following 
strict guidelines set forth by the crime fighters: 


e Configure an |1P network, as depicted in Figure 13-47, using EIGRP as the routing protocol 
and 2001 as the Autonomous System ID. 


Figure 13-47. Crime Fighters Network, Part I! 
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e Configure the Frame Relay network as depicted in Figure 13-47. 
e Configure the DLSw+ peers on the network as depicted in Figure 13-48. Abide by the 


following guidelines: 


Figure 13-48. Crime Fighters Network with DLSw Peers 
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- Configure DLSw+ Lite between the wolf router Ethernet 2 segment and 
trashman's Ethernet segment. This is the only remote-peer statement that you can 
configure on the wolf router. 


- Configure DLSw+ so that trashman only has visibility and reachability to the 
Ethernet segment that the H.O.0.V.E.R.2 mainframe is on. No other DLSw+ peer 
should see the Ethernet segment that H.O.O.V.E.R.2 resides on. 


- Configure a dynamic SNA TCP peer from lone_rhino to the wolf router. This peer 
should time out after seven minutes without traffic. Only SNA can bring up this 
dynamic peer. The peer should transport only SNA between the Ethernet segment 
of lone_rhino and the EO segment of the wolf router, where the H.O.O0.V.E.R 
mainframe resides. 


- Configure a TCP peer to transport data from the Token Ring segment on the 
beerbelly router to the Ethernet segment that the H.O.0.V.E.R mainframe resides 
on, on the wolf router. 


- Configure a backup peer from beerbelly to the lone_rhino router, backing up the 
peer from beerbelly to the wolf. The backup peer should remain up as long as a 
circuit is active. If the primary peer becomes active, ensure that it will not tear 
down the active circuit on the backup peer. 931 


Lab Objectives 


e Configure the Crime Fighters Network as depicted in Figures 13-47 and 13-48. Configure 
IP as denoted. Use EIGRP as the routing protocol, with an Autonomous System ID of 2001. 
Because this network is an evolution of the previous lab, you might use that same 
configuration to begin this lab. 

e Use Frame Relay as the data link protocol on the WAN. Configure a Frame Relay multipoint 
network between the wolf, lone_rhino, and trashman routers. Configure a Frame Relay 
point-to-point network between the wolf and beerbelly routers. 

e Configure the DLSw+ peers on the network as depicted in Figure 13-48. Abide by the 
following guidelines: 


- Configure DLSw+ Lite between the wolf router Ethernet 2 segment and 
trashman's Ethernet segment. This is the only remote-peer statement that you 
can configure on the wolf router. 


- Configure DLSw+ so that trashman only has visibility and reachability to the 
Ethernet segment that the H.O.0.V.E.R.2 mainframe is on. No other DLSw+ peer 
should see the Ethernet segment that H.O.O.V.E.R.2 resides on. 


- Configure a dynamic SNA TCP peer from lone_rhino to the wolf router. This peer 
should time out after seven minutes without traffic. Only SNA can bring up this 
dynamic peer. The peer should transport only SNA between the Ethernet segment 
of lone_rhino and the EO segment of the wolf router, where the H.O.0.V.E.R 
mainframe resides. 


- Configure a TCP peer to transport data from the Token Ring segment on the 
beerbelly router to the Ethernet segment that the H.O.0.V.E.R mainframe resides 
on, on the wolf router. 


- Configure a backup peer from trashman to the lone_rhino router, backing up the 
peer from trashman to the wolf. The backup peer should remain up as long as a 
circuit is active. If the primary peer becomes active, ensure that it will not tear 
down the active circuit on the backup peer. 


Equipment Needed 


e Five Cisco routers. Four will be connected through V.35 back-to-back cables or in a similar 
manner to a Frame Relay switch. 

e Five LANs segments, provided by hubs or switches. One router will need two Ethernet 
interfaces. One other router will need to be a Token Ring interface. 


Physical Layout and Prestaging 


Note: You can use the same Frame Relay configuration from the previous lab. 


e Connect the hubs and serial cables to the routers, as shown in Figure 13-47. 
e A Frame Relay switch with three PVCs also is required. Example 13-56 lists the Frame 
Relay configuration used in this lab. 


Example 13-56 Frame Relay Switch Configuration 
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hostname frame_switch 

! 

interface Serial0O 

no ip address 

encapsulation frame-relay 

no fair-queue 

clockrate 148000 

frame-relay intf-type dce 

frame-relay route 111 interface Seriall 110 
! 

interface Seriall 

no ip address 

encapsulation frame-relay 

clockrate 148000 

frame-relay intf-type dce 

frame-relay route 110 interface SerialO 111 
frame-relay route 130 interface Serial3 131 
frame-relay route 180 interface Serial5 181 
! 

<<<text omitted>>> 

! 

interface Serial3 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay intf-type dce 

frame-relay route 131 interface Seriall 130 
! 
<<<text omitted>>> 

! 
interface Serial5 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay intf-type dce 

frame-relay route 181 interface Seriall 180 
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Lab 27: DLSw+ TCP, LLC2, Promiscuous, Dynamic, and Backup Peer 
Configuration—Part Il 


Lab Walkthrough 


This lab continues from the previous lab; the only difference in the physical layout is that of the wolf 
router, which now has two Ethernet interfaces and no Token Ring interfaces. If you use the same 
configurations from the previous lab, be sure to disable transparent bridging on the WAN and RSRB. 


Configure the Frame Relay switch and attach the four routers in a back-to-back manner to the frame 
switch. Use V.35 cables or CSU/DSUs with crossover cables to connect the routers. Create the four 
Ethernet LANs and Token Ring LANs by the using switches and hubs/MAUs, as illustrated previously 


in Figure 13-47. 


When the physical connections are complete, assign IP addresses to all LAN and WAN interfaces, as 
depicted in Figure 13-47. On the wolf router, configure a Frame Relay multipoint network to the 
routers lone_rhino and trashman. Configure a Frame Relay point-to-point network between the wolf 
router and the beerbelly router. Configure EIGRP as the routing protocol. For trashman's subnet to 
be advertised to the lone_rhino router, you must disable EIGRP split horizon on the wolf router. 
Example 13-57 provides the EIGRP and the frame configurations of the wolf, lone_rhino, trashman, 
and beerbelly routers. 


Example 13-57 Frame Relay and EI GRP Configurations of wolf, lone_ rhino, 
and beerbelly 


hostname wolf 

! 

<<<text omitted>>> 

! 

interface Serial0 

no ip address 

no ip directed-broadcast 
encapsulation frame-relay 

no ip mroute-cache 

logging event subif-link-status 
logging event dlci-status-—change 
frame-relay lmi-type cisco 

! 

interface Serial0O.1 multipoint 

ip address 172.16.1.1 255.255.255.0 


interface Serial0.2 point-to-point 


no ip directed-broadcast 
_frame-relay interface-dlci 180 = *~ Inverse ARP 
! 


<<<text omitted>>> 
! 
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~ Routing BIGRE 
passive-interface Ethernet0O 
network 172.16.0.0 


no auto-summary 
! 


hostname lone_rhino 

! 

<<<text omitted>>> 

! 

interface Serial0O 

ip address 172.16.1.5 255.255.255.0 
encapsulation frame-relay 


<<<text omitted>>> 


network 172.16.0.0 


no auto-summary 
! 


hostname trashman 

! 

<<<text omitted>>> 

! 

interface Serial0O 

ip address 172.16.1.6 255.255.255.0 
no ip directed-broadcast 
encapsulation frame-relay 

no ip mroute-cache 


frame-relay lmi-type cisco 
! 


<<<text omitted>>> 


network 172.16.0.0 


no auto-summary 
! 


hostname beerbelly 

! 

<<<text omitted>>> 

! 

interface Serial0d 

ip address 172.16.2.2 255.255.255.0 
encapsulation frame-relay 
frame-relay interface-dlici 181 
frame-relay lmi-type cisco 

! 

<<<text omitted>>> 

! 

router eigrp 2001 


network 172.16.0.0 
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no auto-summary 
! 


The abbreviated process to configure DLSw-+ is as follows: 


Step 1. Configure loopback address for peers. 
Step 2. Configure local peers. 
Step 3. Configure SRB or transparent bridging. 
Step 4. Configure remote peers. 
Figure 13-49 illustrates the network, highlighting some more specific configuration details. Figure 13- 


49 illustrates bridge groups, virtual rings, and the loopback address that you will use for local and 
remote peers. 


Figure 13-49. Crime Fighters Network with DLSw Peers 
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Step 1 in configuring DLSW is to assign the loopback interfaces, as denoted in Figure 13-49. EIGRP 
will propagate these addresses because they are in the same major bit boundary configured 
previously. When you can ping all the loopback interfaces, move on to the next step. 936 


Step 2 involves assigning local peers to the routers. In this model, you accomplish this by using the 
global router command dilsw local-peer peer-id loopback_IP_address. You are allowed to 
configure only a single remote-peer on the wolf router. Therefore, the wolf's local peer must be 
configured as promiscuous. If you want to save some time configuring remote peers, you also 
should configure the local peer of the lone_rhino router to be promiscuous. The syntax to configure 
the local peer on the wolf is as follows: 


wolf (config) #dlsw local-peer peer-id 172.16.192.1 promiscuous 


The third step involves configuring transparent or source-route bridging on the routers and 
interfaces that you want to add to the DLSw domain. For the routers lone_rhino, trashman, and 
beerbelly, this is accomplished in the exact same manner as it was in the previous lab; therefore, 
we will not spend a lot of time going over the details of this portion of the configuration. The wolf 
router, on the other hand, needs two bridge groups configured. Ethernet 0 will be in bridge group 1, 
and Ethernet 2 will be in bridge group 2. You need to do this to set up the DLSw bridge list when 
you configure the remote peers. Example 13-58 lists the transparent bridging portion and DLSw 


portion of the wolf router to this point. 


Example 13-58 Transparent Bridging on the wolf Router 


hostname wolf 
! 


disw local-peer peer-id 172.16.192.1 promiscuous “Local Peer, Loopback 20 
disw bridge-group 10 ink to bridge 1 

disw bridge-group 20S Linkn to bridge 2 

! 

interface Loopback20 


ip address 172.16.192.1 255.255.255.252 
no ip directed-broadcast 

! 
interface Ethernet0O 

ip address 172.16.55.1 255.255.255.0 

no ip directed-broadcast 

media-type 10BaseT 


bridge-group 100 Fn bridge 1 
! 

<<<text omitted>>> 

! 

interface Ethernet2 

no ip address 


no ip directed-broadcast 
media-type 10BaseT 


bridge-group 200 tn riage 2 
! 


<<<text omitted>>> 
! 


‘~ sTP for bridge 1 and bridge 2 


bridge 2 protocol ieee 


When the transparent bridge groups are configured, they need to be attached to DLSw domain with 
the command dlsw bridge-group X command. This command is demonstrated in the previous 
example for the wolf router. For source-route bridging, such as found on the beerbelly router, the 
virtual ring links the SRB to the DLSw domain. Example 13-59 lists the configuration of the beerbelly 
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router to this point. 


Example 13-59 SRB Configuration on the beerbelly Router 


hostname beerbelly 
! 
<<<text omitted>>> 


interface Loopback20 
ip address 172.16.192.5 255.255.255.252 
! 
interface Serial0 
ip address 172.16.2.2 255.255.255.0 
encapsulation frame-relay 
frame-relay interface-dlici 181 
frame-relay lmi-type cisco 
! 
<<<text omitted>>> 
! 
interface TokenRing0O 
ip address 172.16.3.1 255.255.255.0 
ring-speed 16 
multiring all 
source-bridge 21101 = *~ srg enabled 
! 
<<<text omitted>>> 
! 
router eigrp 2001 
network 172.16.0.0 
no auto-summary 
! 
<<<text omitted>>> 


beerbelly# 


Step 4 of the DLSw+ configuration process involves configuring remote peers for all the routers. All 
of the remote peers are different in this model, so we will focus on a router at a time, starting with 
the wolf router. 


The wolf router is allowed only one remote peer, and that is why its local peer is configured as 
promiscuous. The one remote peer that you need to define is a DLSw+ Lite or LLC2 peer to the 
trashman router. You also must limit what Ethernet segments the router trashman has reachability 
to. To accomplish this, use a DLSw bridge list defining only bridge 2. The bridge list then will be 
attached to the remote peer statement for the trashman router. When configuring a LLC2 peer, you 
also need to add a frame relay map IIc2 statement to the SO.1 interface. Example 13-60 lists the 


DLSw configuration of the wolf router. 


Example 13-60 DLSw Configuration of the wolf Router 


hostname wolf 

! 

<<<text omitted>>> 
! 
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disw local-peer peer-id 172.16.192.1 promiscuous 


dlsw bridge-group 2 
! 
interface Loopback20 
ip address 172.16.192.1 255.255.255.252 
no ip directed-broadcast 
! 
interface Ethernet0O 
ip address 172.16.55.1 255.255.255.0 
no ip directed-broadcast 
media-type 10BaseT 


bridge-group1 = * Bridge group 1 
! 

<<<text omitted>>> 

! 

interface Ethernet2 

no ip address 


no ip directed-broadcast 

media-type 10BaseT 

bridge-group 200 Bridge group 2 
! 
<<<text omitted>>> 

! 
interface Serial0 

no ip address 

no ip directed-broadcast 

encapsulation frame-relay 

no ip mroute-cache 

logging event subif-link-status 

logging event dlci-status-—change 
frame-relay lmi-type cisco 

! 
interface Serial0.1 multipoint 

ip address 172.16.1.1 255.255.255.0 

no ip directed-broadcast 

no ip split-horizon eigrp 2001 

‘~ nc2 MAP statement for DLSW 

frame-relay map ip 172.16.1.5 110 broadcast 
frame-relay map ip 172.16.1.6 130 broadcast 
! 

interface Serial0.2 point-to-point 

ip address 172.16.2.1 255.255.255.0 

no ip directed-broadcast 

frame-relay interface-dici 180 

! 

<<<text omitted>>> 

! 

router eigrp 2001 

network 172.16.0.0 

no auto-summary 

! 
bridge 1 protocol ieee 
bridge 2 protocol ieee 
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Example 13-61 represents the other side of the configuration, the trashman router. 


Example 13-61 DLSw Configuration of the trashman Router 


hostname trashman 
! 
<<<text omitted>>> 
! 
dlsw local-peer peer-id 172.16.192.9 
disw remote-peer 0 frame-relay interface Serial0 131 == *~ LLC? peer 
! 
interface Loopback20 
ip address 172.16.192.9 255.255.255.0 
no ip directed-broadcast 
! 
interface Ethernet0O 
ip address 172.16.6.1 255.255.255.0 
no ip directed-broadcast 
bridge-group 1 
! 
interface Serial0 
ip address 172.16.1.6 255.255.255.0 
no ip directed-broadcast 
encapsulation frame-relay 
no ip mroute-cache 
“~LLc2 map statement 
frame-relay map ip 172.16.1.5 131 broadcast 
frame-relay map ip 172.16.1.1 131 broadcast 
frame-relay lmi-type cisco 
! 
<<<text omitted>>> 
! 
router eigrp 2001 
network 172.16.0.0 
no auto-summary 
! 
<<<text omitted>>> 
! 
bridge 1 protocol ieee 


The remote peer configuration of the beerbelly router involves configuring a primary peer to the 
lone_rhino router and a backup peer to the wolf router. This peer cannot tear down LLC2 session 
when the primary becomes active again. Therefore, you do not want to add the linger option. 
Example 13-62 shows the configuration of the beerbelly router. 


Example 13-62 DLSw Configuration of the beerbelly Router 


hostname beerbelly 
! 


<<<text omitted>>> 

! 

source-bridge ring-group 101 

dlsw local-peer peer-id 172.16.192.5 

disw remote-peer 0 tep 172.16.192.13 = “~~ Primary Peer 
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disw remote-peer 0 tcp 172.16.192.1 backup-peer 172.16.192.13 *~ Backup Peer 
! 
interface Loopback20 
ip address 172.16.192.5 255.255.255.252 
! 
interface Serial0 
ip address 172.16.2.2 255.255.255.0 
encapsulation frame-relay 
frame-relay interface-dlici 181 
frame-relay lmi-type cisco 
! 
<<<text omitted>>> 
! 
interface TokenRingO 
ip address 172.16.3.1 255.255.255.0 
ring-speed 16 
multiring all 
source-bridge 2 1 101 
! 
<<<text omitted>>> 
! 
router eigrp 2001 
network 172.16.0.0 
no auto-summary 


The last remote peer that you need to configure is a dynamic TCP peer from lone_rhino to the wolf 
router. When you configure this peer, you need to include an LSAP-OUTPUT-FILTER to allow only 
SNA to pass. The SAP value for SNA is OxOd0d. To make the peer dynamic, simply add the dynamic 
and inactivity keywords to the remote peer statement. The inactivity timer that you need to specify 
is seven minutes. Example 13-63 lists the configuration of the lone_rhino router. The keepalive 


value and a timeout value automatically are added when a dynamic peer is configured. 


Example 13-63 Configuration of the lone_rhino Router 


hostname lone_rhino 
! 
<<<text omitted>>> 
! 


dlsw local-peer peer-id 172.16.192.13 promiscuous 


*~ dynamic peer 

dlsw bridge-group 1 

! 

interface Loopback20 

ip address 172.16.192.13 255.255.255.252 

! 

interface Ethernet0 

ip address 172.16.5.1 255.255.255.0 
bridge-group 1 

! 
interface Serial0 

ip address 172.16.1.5 255.255.255.0 
encapsulation frame-relay 

frame-relay map ip 172.16.1.6 111 broadcast 
frame-relay map ip 172.16.1.1 111 broadcast 
! 

<<<text omitted>>> 

! 


router eigrp 2001 
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network 172.16.0.0 


no auto-summary 
! 


ip classless 
no ip http server 
! 


access-list 201 permit 0x0000 oxop0D ==) “Allow SNA only 
! 
bridge 1 protocol ieee 


You can verify the configuration by viewing peers on the various routers. By deactivating the serial 
link on the lone_rhino router, the backup peer should become active on the beerbelly router. Use 
Windows networking to verify reachability, as we discussed earlier in this chapter. To test the 
dynamic peer, you might want to switch the SAP to NetBIOS and use WIN 9x. It might be hard to 
easily simulate a SAP OxOd. 


Example 13-64 displays all the possible peers on the wolf router, including the backup peer for 
beerbelly. Notice that one peer is an LLC2 peer, and the other two are TCP promiscuous peers. 


Example 13-64 DLSW Peers on the wolf Router 


wolf#show dlsw peer 


Peers: state pkts_rx pkts_tx type drops ckts TCP uptime 
LLC2 Se0.1 130 CONNECT 50 50 cont 0 0 = 0032338 
TCP 172.16.192..5 CONNECT 14 53 prom 0 0 0 00:06:19 
TCP VI2<16.192 13 CONNECT 12 9 prom 0 0 0 00201202 


Total number of connected peers: 3 
Total number of connections: 3 


wolf# 


Example 13-65 displays all the possible peers on the lone_rhino router, including the dynamic peer 
for the wolf router. Notice that one peer is an LLC2 peer, and the other two are TCP promiscuous. 


Example 13-65 DLSW Peers on the lone_ rhino Router 


wolf#show dlsw peer 


Peers: state pkts_rx pkts_tx type drops ckts TCP uptime 
TCP 172.216.1925 CONNECT 26 32 prom 0 0 0 00:12:34 
TCP A72.16:..192 4 CONNECT 2 5 dynam 0 0 0 00:00:06 


Total number of connected peers: 2 
Total number of connections: 2 


lone_rhino# 


Example 13-66 displays all the possible peers on the beerbelly router. Notice that the backup peer is 
down at this time. 


Example 13-66 DLSW Peers on the beerbelly Router 
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wolf#show dlsw peer 


Peers: state pkts_rx 
TCP 172.16:.192.13 CONNECT 43 
TCP 172.216.1920 DISCONN 0 


Total number of connected peers: 1 
Total number of connections: 1 


beerbelly# 


pets tx 
a2 


0 


type 
conf 


conf 


drops: ickts. TCP uptime 


0 


0 


O QOELSEZ3 
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Lab 28: DLSw+ Reachability, Border Peers, Demand Peers, and 
Resilient Peers—Part | 


Practical Scenario 


DLSw+ provides a way to control explorers and scale a DLSW network with the concept of border 
peers. Border peers greatly reduce the number of explorers on the link and the configuration of 
remote peers. This lab will give you experience configuring DLSw+ border peers, peer groups, and 
demand peers. This lab will also give you practice configuring DLSw resiliency. 


Lab Exercise 


The United States and Canada have established a tourism network. The tourism network will allow 
tourists to access to the latest information about popular sites in each country. Your task is to 
configure DLSw with the following guidelines: 


e Configure an 1P network as depicted in Figure 13-50 using EIGRP as the routing protocol 
and 2001 as the Autonomous System ID. 


Figure 13-50. U.S.- Canadian Tourism Network 
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e Configure the WAN links to all use HDLC protocol. Configure the dual WAN links between 
the us_tour router and the us_border router so that one is a backup for the other. Both 
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links should not be active at the same time. 
e Configure the DLSw peers on the network as depicted in Figure 13-50. Abide by the 
following guidelines: 


- Configure any-to-any SNA and NetBIOS reachability from all the Ethernet 
segments in the network. 


- Do not configure a peer between the us_tour and the canada_tour routers. 
- Do not bridge across any WAN interfaces. 


- Configure DLSw reachability such so the us_tour router advertises reachability to 
the station named US_ STATIONS and the Canada_tour router advertises 
reachability to the station named CANADA_ STATIONS. 


- Configure the peer between the us_tour router and the us_ border router to 
remain up during the loss of the primary HDLC link. This peer should not drop while 
the network is converging over the new link. 


Lab Objectives 


e Configure the network as depicted in Figure 13-50. Configure IP as denoted. Use EIGRP as 
the routing protocol, with an Autonomous System ID of 2001. 

e Configure the WAN links to all use HDLC protocol. Configure the dual WAN links between 
the us_tour router and the us_border router so that one is a backup for the other. Both 
links cannot be active at the same time. 

e Configure the DLSw peer groups and border peers as depicted in Figure 13-50. Abide by 
the following guidelines: 


- Configure two DLSw peer groups. Peer group 10 contains the U.S. routers, and 
peer group 20 contains the Canadian routers. Configure reachability between these 
two groups. 


- Configure DLSw so that a peer-on-demand will be created between the us_tour 
and the canada_tour routers. Do not configure a peer between the us_tour and 
canada_tour routers. 


- Configure DLSw reachability so that the us_tour router advertises reachability to 
the station named US_ STATIONS and the Canada_tour router advertises 
reachability to the station named CANADA_ STATIONS. 


- Configure the peer between the us_tour router and the us_ border router to 
remain up during the loss of the primary HDLC link. This peer should not drop while 
the network is converging over the new link. 


Equipment Needed 


e Four Cisco routers, connected together through V.35 back-to-back cables or in a similar 
manner. 

e Four LANs segments, provided by hubs or switches. The LAN topology is not significant for 
this lab. 


Physical Layout and Prestaging 
945 


e Connect the hubs and serial cables to the routers as shown in Figure 13-50. 
e You might want to use Windows 9x workstations to test the peer-on-demand configuration. 
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Lab 28: DLSw+ Reachability, Border Peers, Demand Peers, and 
Resilient Peers—Part Il 


Lab Walkthrough 
Begin by attaching the four routers in a back-to-back manner as illustrated in Figure 13-50. 


When the physical connections are complete, assign |P addresses to all LAN and WAN 
interfaces, as depicted in Figure 13-50. To configure the WAN interfaces, one end of the link 
must be configured as DCE if you are using back-to-back cables. Use the interface command 
clock rate speed to set one side of the link to be DCE. The WAN protocol is HDLC, so no 
further configuration is necessary to make the link active. The model specifies that you can 
have only one serial link active at a time between the us_ border and us_tour routers. To 
configure one link to back up the other, use the backup interface command. Example 13-67 


lists the serial configuration of the us_ border router. 


Example 13-67 Serial Configuration of the us_ border Router 


hostname us_border 
! 
<<<text omitted>>> 
! 
interface SerialO 
ip address 128.10.101.1 255.255.255.252 
no fair-—queue 
clockrate 64000 
! 
interface Seriall 
backup delay 0 0 
backup interface Serial7 
ip address 128.10.10.6 255.255.255.252 
clockrate 64000 
! 
<<<text omitted>>> 
' 
interface Serial7 
ip address 128.10.10.1 255.255.255.252 
clockrate 64000 
! 
<<<text omitted>>> 
! 
router eigrp 2001 
network 128.10.0.0 
no auto-summary 


When you can ping all of the routers' local interfaces, configure EIGRP as the routing 
protocol. This model has two major subnets; thus, the canada_border router will need two 
network statements, one for 128.20.0.0 and one for 128.10.0.0. Example 13-68 lists the 


EIGRP configuration of the canada_border router. 


Example 13-68 EIGRP Configuration of the canada_ border Router 
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! 

router eigrp 2001 
network 128.10.0.0 
network 128.20.0.0 


no auto-summary 
! 


Begin the DLSw configuration by configuring the peer between the U.S. routers first. Recall 
the following four-step process for configuring DLSw: 


Step 1. Configure loopback address for peers. 
Step 2. Configure local peers. 
Step 3. Configure SRB or transparent bridging. 


Step 4. Configure remote peers. 


Begin by configuring loopback addresses on all the routers. You will use these for the local 
and remote peers. 


Step 2 calls for configuring local peers. The U.S. routers will be in peer group 10. To the local 
peer to a peer group, use the group keyword on the local-peer statement. The us_ border 
router actually will be the border peer for peer group 10. To configure a border peer, simply 
include the keyword border on the local-peer statement. The Canada routers will be in peer 
group 20, and the canada_border router will be the border peer for that peer group. 


To configure transparent bridging to satisfy Step 3, add the Ethernet interface to a bridge 
group with the interface command bridge-group x. STP also must be enabled with the global 
command bridge 1 protocol | EEE, where 1 is the transparent bridge number. The 
transparent bridging portion for all of the router configurations will be identical. Example 13- 
69 lists the transparent bridging configuration of the us_tour router. This example also 
demonstrates the command needed to attach the bridge group to a DLSw domain. 


Example 13-69 Transparent Bridging Configuration 


disw bridge-group 1 attach bridge 1 to DLSW 
! 

<<<text omitted>>> 

! 

interface Ethernet0 

ip address 128.10.1.1 255.255.255.0 
no ip directed-broadcast 
media-type 10BaseT 

bridge-group 1 

! 

<<<text omitted>>> 

! 


bridge 1 protocol ieee 
! 


Step 4 involves configuring a TCP peer from the us_tour router to the us_border router. This 
peer needs to be configured so that it will not drop when a serial line converges. To prevent a 
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peer from dropping during a link failure, assign a timeout 500 value and a keepalive 0 
value to the remote peer on both sides of the link. The us_tour router will need to be 
configured for a peer-on-demand from the canada_tour router. To configure a peer-on- 
demand, use the following global command: 


us_tour(config) #dlsw peer-—on-demand-defaults tcp-queue-max 50 


The last DLSw command that you need to configure on the us_tour router is for DLSw 
reachability. To advertise reachability to the station US_ STATION, use the following DLSw 
command: 


us_tour(config) #dlsw icanreach netbios-name US_STATIONS 


Example 13-70 shows the complete configuration of the us_tour router. 


Example 13-70 Configuration of the us_ tour Router 


hostname us_tour 
! 
<<<text omitted>>> 
! 
dlsw local-peer peer-id 128.10.128.9 group 10 
dlisw remote-peer 0 tcp 128.10.128.1 keepalive 0 timeout 500 
dlsw icanreach netbios-name US_STATIONS 
dlsw peer—on-demand-defaults tcp-queue-max 50 
dlsw bridge-group 1 
! 
! 
interface Loopback20 
ip address 128.10.128.9 255.255.255.252 
no ip directed—-broadcast 
! 
interface Ethernet0 
ip address 128.10.1.1 255.255.255.0 
no ip directed-broadcast 
media-type 10BaseT 
bridge-group 1 
! 
<<<text omitted>>> 
! 
interface Serial0 
ip address 128.10.10.5 255.255.255.252 
no ip directed-broadcast 
no ip mroute-cache 
! 
interface Seriall 
ip address 128.10.10.1 255.255.255.252 
no ip directed-broadcast 
! 
<<<text omitted>>> 
! 
router eigrp 2001 
network 128.10.0.0 
no auto-summary 
! 
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<<<text omitted>>> 
! 


bridge 1 protocol ieee 
! 


The us_border peer has one additional peer configured to the canada_border router. Example 
13-71 shows the complete configuration of the us_border router. 


Example 13-71 Configuration of the us_ border Router 


hostname us_border 

! 

dlsw local-peer peer-id 128.10.128.1 group 10 border 
dlsw remote-peer 0 tcp 128.10.128.9 keepalive 0 timeout 500 
dlsw remote-peer 0 tcp 128.10.128.5 
dlsw bridge-group 1 

! 

interface Loopback20 

ip address 128.10.128.1 255.255.255.252 
! 

interface Ethernet0 

ip address 128.10.100.1 255.255.255.0 
bridge-group 1 

! 

interface Serial0 

ip address 128.10.101.1 255.255.255.252 
no fair-—queue 

clockrate 64000 

i] 

interface Seriall 

backup delay 0 0 

backup interface Serial7 

ip address 128.10.10.6 255.255.255.252 
clockrate 64000 

! 

<<<text omitted>>> 

! 

interface Serial7 

ip address 128.10.10.1 255.255.255.252 
clockrate 64000 

! 

<<<text omitted>>> 

! 

router eigrp 2001 

network 128.10.0.0 

no auto-summary 

! 

<<<text omitted>>> 

! 
bridge 1 protocol ieee 


To view the static NetBIOS reachability from the us_border peer, enter the show disw 
reachability command as demonstrated in Example 13-72. You should now see the NetBIOS 


name US_STATIONS being reported to the border router. 
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Example 13-72 Viewing the Reachability on the us_ border Router 


us_border#show dlsw reachability 
DLSw Remote MAC address reachability cache list 
Mac Addr status Loc. port sigalg 


DLSw Local MAC address reachability cache list 
Mac Addr status Loc. peer 
0000.613c.dc82 FOUND REMOTE 128.10.128.5(2065) 


DLSw Local NetBIOS Name reachability cache list 
NetBIOS Name status Loc. port sage 


DLSw Remote NetBIOS Name reachability cache list 
NetBIOS Name status LOC. peer 


us_border# 


The configuration of canada_border router and canada_tour routers mirrors that of the two U. 
S. routers. Example 13-73 shows the complete configurations of these routers. 


Example 13-73 Configurations of the Canada Routers 


hostname canada_border 

! 

<<<text omitted>>> 

! 

dlsw local-peer peer-id 128.10.128.5 group 20 border 
dlsw remote-peer 0 tcp 128.10.128.1 
dlsw remote-peer 0 tcp 128.10.128.13 
dlsw bridge-group 1 

! 

! 

interface Loopback20 

ip address 128.10.128.5 255.255.255.252 
! 

interface Ethernet0 

ip address 128.20.100.1 255.255.255.0 
bridge-group 1 

! 

interface Serial0 

ip address 128.10.101.2 255.255.255.252 
no fair-—queue 

! 

interface Seriall 

ip address 128.20.10.2 255.255.255.252 
clockrate 64000 

! 

<<<text omitted>>> 

! 

router eigrp 2001 

network 128.10.0.0 

network 128.20.0.0 

no auto-summary 

! 
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<<<text omitted>>> 
! 


bridge 1 protocol ieee 
! 


hostname canada_tour 
! 
! 
dlsw local-peer peer-id 128.10.128.13 group 20 
dlisw remote-peer 0 tcp 128.10.128.5 
dlsw icanreach netbios-—name CANADA_STATIONS 
dlsw peer-on-demand-defaults tcp-queue-max 50 
dlsw bridge-group 1 
! 
<<<text omitted>>> 
! 
interface Loopback20 
ip address 128.10.128.13 255.255.255.252 
! 
interface Ethernet0 
ip address 128.20.1.1 255.255.255.0 
bridge-group 1 
! 
interface Serial0 
ip address 128.20.10.1 255.255.255.252 
no fair-—queue 
! 
<<<text omitted>>> 
! 
router eigrp 2001 
network 128.20.0.0 
network 128.10.0.0 
no auto-summary 
! 
<<<text omitted>>> 
! 
bridge 1 protocol ieee 


To verify the configuration, view the DLSw reachability on the border routers. You should see 
the static |CANREACH from the peers within the same group as the border peer. As 
mentioned previously, a Windows workstation is a great way to test DLSw. By putting 
workstations on the various LAN segments, you can generate traffic, create circuits, and force 
explorers. Example 13-74 shows a workstation connected to the DLSw domain, issuing an 
explorer for the NetBIOS station BORDER-PATROL. 


Example 13-74 Verifying the Configuration 


us_border#show dlsw reachability 
DLSw Remote MAC address reachability cache list 
Mac Addr status LOC; port nga ld 


DLSw Local MAC address reachability cache list 

Mac Addr status Loc. peer 
0000.613c.dc82 FOUND REMOTE 128.10.128.5(2065) 
DLSw Local NetBIOS Name reachability cache list 
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NetBIOS Name status Loc. port rave 


a ee 

DLSw Remote NetBIOS Name reachability cache list 
NetBIOS Name status hoc. peer 

TOURIST FOUND REMOTE 128.10.128.5(2065) 
US_STATIONS UNCONFIRM REMOTE 128.10.128.9(2065) 


us_border# 


Verifying the DLSw peer connections and DLSw capabilities is another way to ensure that the 
DLSw network is operating. Example 13-75 illustrates the show dilsw peer command on the 


canada_border router. 


Example 13-75 Verifying the Peers on the canada_ border Router 


canada_border#show dlsw peer 


Peers: state pkts.rx pkts_tx type drops ckts TCP uptime 
TCP 128.10). 126-1. CONNECT 65 85 conf 0 0 0 O0rs2220 
TCP’ 1265.10.128 13 CONNECT 67 103 conf 0 0 Ol! 00's 33:00 


Total number of connected peers: 2 
Total number of connections: Zz 


canada_border# 
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Chapter 14. Understanding IP Access Lists 


In many modern networks, there eventually comes a point when full IP reachability is no 
longer desirable. The reasons for this can range from security concerns to political concerns, 
such as the merging of two companies with the same IP address space assigned. And sooner, 
or later, the request will come "Can we just allow...?", and you will be forced to deal with 
access lists. 


Controlling routing updates, traffic paths, and protocols can be one of the more challenging 
aspects of router configuration. Understanding binary math and how it relates to the access 
list is critical to access lists. Critical to traffic filters is understanding the protocol 
characteristics of the protocol that you are trying to filter. 


This chapter covers access lists in general and explains why binary arithmetic is important. It 
also covers the different types of IP access lists: standard, extended, dynamic, and named. 


NOTE 


Understanding the way a protocol works is key to writing a filter for it. When 
writing a filter for an IP protocol, you must know what port a client uses to 
initiate a connection to a server. You also must know the port number on which 
the server sends data to the client because the two might not be the same. As 
you will see later in this section, FTP is a good example of a protocol that sends 
data on a different port than the port on which the session is initiated. If you're 
having problems writing specific IP traffic filters, consult a reference such as 
Richard Stevens' TCP/IP Illustrated or Douglas Comer's Internetworking with 
TCP/IP for more details on how that specific protocol might be operating. 
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Understanding How Access Lists Operate 


Essentially, an access list is a set of conditions that are executed sequentially from top to 
bottom. When a condition is matched, no further comparisons are made, and a true or false 
result is returned to the process that called the list. The types of access lists have grown over 
the years. Cisco |OS Software Release 12.0. adds some extended ranges for IP, as Example 


14-1 lists. 


Example 14-1 Access List Range in Cisco |1OS Software Release 12.0. 


router (config) #access-list ? 
<l=99> IP standard access list 
<LO0=L99> IP extended access list 
<1000-1099> IPX SAP access list 
<1100-1199> Extended 48-bit MAC address access list 
<1200-1299> IPX summary address access list 
<1300-1999> IP standard access list (expanded range) 


<200=299> Protocol type-code access list 
<2000-2699> IP extended access list (expanded range) 
<300-399> DECnet access list 
<400-499> XNS standard access list 
<500-599> XNS extended access list 
<600-699> Appletalk access list 
<700-799> 48-bit MAC address access list 
<800=8'99> IPX standard access list 
<900=999> IPX extended access list 


Standard access lists filter based on one condition, the match of an address. When you think 
of access lists, think of them as conditions that are either true or false; they return this result 
to the process that called them. It is important to think of them in this way because you will 
use access lists not only to filter packets on interfaces, but also for route maps, 
redistribution, and other features, such as Network Address Translation (NAT). Therefore, 
don't limit your thinking of access lists in terms of "networks" or "packets," but consider what 
process is calling the access list and what is returned to that process. The access list merely 
returns the result of the condition in the list, either true or false. The process that called the 
list is then carried out or denied based on the result of the condition. 


You should follow a few rules and suggestions when configuring any access list: 


e There is an implicit deny at the end of all access lists. This will not appear in your 
configuration listing. 

e The access list is executed from top to bottom in sequential order. When a condition is 
true, processing in the list comes to a halt, and no further comparisons are made. 

e Access list entries should filter in the order from specific to general. Specific hosts 
should be denied first, and groups or general filters should come last. 

e New lines are always added to the end of the access list. A no access-list x 
command will remove the whole list; you cannot selectively add and remove lines. 

e An undefined access list will permit any or all traffic. 

e When configuring an access list, always configure the list first and then apply it to the 
process, whether it's a standard packet filter, a route map, or a redistribute 
statement. This way, it is easy to test your list and remove it quickly. 

e An IP access list will send an ICMP host unreachable message to the sender of the 
packet and then will discard the packet into the bit bucket. 
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e Apply the filter as close as possible to the source of traffic that you want to filter. 


Security filters usually block inbound access, whereas traffic filters usually prohibit 
traffic from crossing a link and use outbound filters. 

Care should be used whenever removing an access list. If the access list is applied to 
a production interface and the access list is removed, there will be a default deny any 
applied to the interface, and all traffic will be halted. 

Outbound filters do not affect traffic originating on the router. 
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Access Lists, Wildcard Masks, and Binary Math 


Everything digital speaks the language of ones and zeros, and access lists are no exception. 
Standard and extended access lists use the concept of a wildcard mask, a binary number 
expressed in dotted-decimal notation. In an access list, the address bits, or the first address 
entry, are compared to a corresponding wildcard mask. If the wildcard mask has a 0 bit, it 
means that the corresponding bit location in the access list address must match the bit value 
of the compared packet. This is sometimes called a care bit. If the wildcard mask has a 1, it 
means that this bit value will not be compared to anything; sometimes it is called a don't 
care bit. The concept of the care and don't care bits becomes clear only when everything is 
broken down into binary form. 


Figure 14-1 shows a simple access list configured on the router's Ethernet 0/0 port. The text 
following the figure provides a step-by-step look at how this works. 


Figure 14-1. Simple Access List Example 
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Inbound IP packet 
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The first step in understanding the access list is to write out both of the lines of the access 
list in binary. Figure 14-1 shows the following access list: 


access-list 1 permit 128.128.2.0 0.0.255.255 


Writing out the first part of the list in binary yields the following: 


1128 /.128 |.2 /.0 
/1000 0000 1000 0000 0000 0010 (0000 0000 


You will use the first part of the access list as the comparison bits. The second half of the 
access list tells what bits you should care about or must match from the comparison bits. 
Writing the second half of the access list in binary yields this result: 


0000 0000 0000 0000 DUEL Diit ets Kg ta 


Now, if you lay the two together, you can see directly what bits are significant. In this case, 
you can see that you care about every bit in the first two octets only because every value in 
them is set to 0. 


[1000 0000 [1000 0000 0 000 0010 0 000 0000 
0000 0000 0000 0000 [1111 cl [2111 1111 


Essentially, the first bit of whatever address you compare this access list to must be a 1, and 
the next 7 bits must be 0. The second octet says the same thing. In the third and fourth 
octet, there are all 1 bits in the wildcard mask. Therefore, you don't care whether these bits 
match because you're basically ignoring the last two octets; this means that these bits can be 
either a1 ora 0. 


This example uses a standard access list, so the router will use the source IP address of the 
incoming packet for its comparison. Breaking out the source address, you have the following: 


126 .128 /.1 .100 
[1000 0000 1000 0000 [0000 0001 (0100 0100 


Examining the first bit, you can see that it is a 1. From the previous comparison, you know 
that you care about this bit and that it has to be a 1. The second bit is 0; again, the wildcard 
mask indicates that you care about this bit and that it has to be a 0. Stepping through the 
rest of the example, it becomes apparent that this comparison will yield a true or positive 
result. 


The process that the router uses is called a logical OR, or a Boolean OR. Much as a router 
uses a logical AND between the destination packet's address and the mask on the router's 
interface to find out whether a particular address resides on that subnet, a logical OR is used 
in access lists. 


A logical AND states that when comparing two binary numbers, the result will yield a 1 if, and 
only if, both bits are 1. For example, performing a logical AND on two addresses, 128.128.1.1 
and 255.255.255.0, would yield 128.128.1.0. 


[1000 0000 [1000 0000 0000 0001 [0000 0001 
1111 1111 11111111 1111 1111 0000 0000 
1000 0000 1000 0000 [0000 0001 0000 0000 


Yields: 128.128.1.0 


A logical OR is just the opposite. It states that when comparing two binary numbers, the 
result will yield a O if and only if both bits are 0. For example, performing a logical OR on the 
same address pair (128.128.1.1 and 255.255.255.0) yields 255.255.255.1. 


1000 0000 1000 0000 0000 0001 0000 0001 


[1111 1111 1111 1111 1111 1111 0000 0000 
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[1111 a a Lid dad PULL 211d 0000 0001 


Yields! 255.255.255.1 


You can now apply the concept of the logical OR to access lists. All access lists, standard or 
extended, yield a true result if a logical OR is performed between the wildcard mask and the 
test address, and if this result equals the result of performing a logical OR between the 
address and mask pair of the access list. For example, assume the use of the following 
standard access list: 


access-list 1 permit 128.128.0.0 0.0.255.255 


You are given two packets with the source addresses of 128.128.1.1 and 128.192.1.1. Which 
address will pass the access list? 


Performing a logical OR on the test address and the wildcard mask, 128.128.1.1 and 
0.0.255.255, yields 128.128.255.255. Next, you can perform a logical OR on the address and 
mask pair of the access list. Performing a logical OR on 128.128.0.0 and 0.0.255.255 yields 
128.128.255.255. Notice that the results are the same, so the access list yields a true result 
for the address 128.128.1.1. Using the second address, you perform a logical OR of 
128.192.1.1 and 0.0.255.255, which yields 128.192.255.255. Compare this result with a 
logical OR of the access list address and mask pair. A logical OR of 128.128.0.0 and 
0.0.255.255 yields 128.128.255.255. Notice this time that the results of 128.128.255.255 
and 128.192.255.255 do not equal each other, so, in this case, this address of 128.192.1.1 
would yield a false result. 


In this example, the bit boundaries are set cleanly to highlight the example, and performing 
the logical OR might seem like a lot of work. But when you start performing the same 
exercise with access lists such as access-list 1 permit 64.35.100.150 0.4.10.254, 
breaking down the numbers in binary form and using the logical OR is the only way to 
understand which bits are significant and which ones are not. 
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Standard IP Access Lists 


Until this point, this chapter has have talked about access lists in a general sense. Now, you will 
learn about the specific types of IP access lists and how to configure them. 


A standard access list falls within the range of 1 and 99, and 1300 and 1999 in Cisco 1OS 
Release 12.0. The log keyword can be added to the end of any access list. It causes an 
informational logging message about the packet that matches the entry to be sent to the 
console. The syntax for the standard IP access list is shown here: 


access-list x {deny | permit} a.b.c.d wildcard_mask {log} 


The a.b.c.d argument is the IP address that the wildcard mask is OR'd with to yield a true or 
false result. 


The standard access list can be applied in a number of ways: 


e Asa packet filter 
e Asa route filter 
e To define significant traffic for a feature such as NAT or a DDR link 


Of course, there are many more, and that is why you can't limit your use of access lists to 
packet filters. 


The example in this section uses standard access lists to filter routes, deny network access, and 
deny virtual terminal access. Figure 14-2 illustrates a simple network running EIGRP as its 
routing protocol. From this example, you can configure multiple access lists to accomplish the 
following: 


Figure 14-2. Standard IP Access List Example 


EGP 192.1624 


Ei tPF 16.1 ad EOQHIP 172.106.1124 


W216. AGA | 116116 


e Prevent jefferson from having a route to 172.16.2.0/24 
e Allow user 172.16.1.129 Telnet access to henry, and deny all other access 


e Prevent all users from 172.16.1.0/24 access to Token Ring 128.200.1.2 961 


Under normal circumstances, with the eigrp no auto-summary command added to each 
router, the route table of the jefferson router would look like Example 14-2. 


Example 14-2 Route Table of the jefferson Router 


jefferson#show ip route 
Codes: C — connected, S —- static, I - IGRP, R —- RIP, M — mobile, B - BGP 
D —- EIGRP, EX — EIGRP external, O - OSPF, IA —- OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 — IS-IS level-2, * - candidate default 
U - per-user static route, o — ODR 
T —- traffic engineered route 


Gateway of last resort is not set 


172.16.0.0/24 is subnetted, 2 subnets 


D 172.16.1.0 [90/297728] via 128.200.1.2, 00:00:31, TokenRing0O 

D 172.16.2.0 [90/323328] via 128.200.1.2, 00:00:18, TokenRing0O 
128.200.0.0/24 is subnetted, 1 subnets 

Cc 128.200.1.0 is directly connected, TokenRing0O 

jefferson# 


One way to prevent jefferson from having access to 172.16.2.0/24 is to use a standard access 
list called by a distribution list on the paine router. Example 14-3 demonstrates the addition of 
the access list to the paine router. Recall from the previous chapters on routing protocols that a 
distribute list is used to filter route updates. 


Example 14-3 Adding a Distribution List Calling a Standard Access List 


paine (config) #router eigrp 2001 

paine(config-—router) #distribute-list 1 out tol 

paine (config-router) #exit 

paine (config) #taccess-—list 1 deny 172.16.2.0 0.0.0.255 
paine (config) #access-list 1 permit any 
paine (config) #exit 
paine# 


Example 14-4 lists the route table of the jefferson router after the access list has been applied. 


Example 14-4 Route Table of the jefferson Router 


jefferson#show ip route 
Codes: C — connected, S — static, I - IGRP, R —- RIP, M — mobile, B - BGP 
D — EIGRP, EX — EIGRP external, O -— OSPF, IA —- OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 — IS-IS level-2, * - candidate default 
U -— per-user static route, o — ODR 
T —- traffic engineered route 


Gateway of last resort is not set 
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172.16.0.0/24 is subnetted, 2 subnets 


D 172.16.1.0 [90/297728] via 128.200.1.2, 00:00:31, TokenRing0 
ic 128.200.1.0 is directly connected, TokenRing0O 
jefferson# 


Following the guidelines listed at the beginning of the chapter, you filter the most specific 
address first and then permit the general address. There is an implicit deny any at the end of 
the access list, so you need to permit routing updates that you are not filtering before the 
implicit deny. Table 14-1 lists access list shortcuts. 


Table 14-1. Access List Shortcuts 


Shortcut 
Address Mask Returns a True Value Keyword 


(0 10.0.0 [2 55.255.255.255 |Any address returns a true any 


b.c.c An exact match to the address host 


a.b.c.d 
To limit Telnet access on the henry router, you can apply a standard access list to the vty ports 
on the routers. Recall from Chapter 1, "The Key Components for Modeling an Internetwork," that 
a show line command lists the vty or the Telnet access ports. Use the following command to 
apply an access list to a port on a router: 


access-class access-list_number {in | out } 


In this case, you want to allow the address 172.16.1.129 Telnet access to henry while denying 
access to all the others. To accomplish this, you need to locate the absolute line numbers of the 
vty sessions. This can be done with the show line command. Then apply an access group, 
calling an access list only to those line numbers. Example 14-5 lists the commands needed to 


limit Telnet access to one address on the router henry. 


Example 14-5 Controlling Telnet Access with Standard IP Access Lists 


henry#show line 


Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns 
= 10 (Gry = = = = = 0 0 0/0 
1 AUX 9600/9600 = = = = = 0 0 0/0 
*~ Telnet sessions 
3 VIY - - = = = 0 0 0/0 
4 VTY = = = = = 0 0 0/0 
o Vix - - 2 = = 0 0 0/0 
6 VTY - = = = = 0 0 0/0 


henry#conft t 

Enter configuration commands, one per line. End with CNTL/Z. 
henry (config) #access-list 1 permit 172.16.1.129 0.0.0.0 
henry (config) #line 2 6 

henry (config-line) #access-—class 1 in 

henry (config-line) #*Z 
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Finally, you must stop all users on subnet 172.16.1.0/24 from accessing the Token Ring 
network. To accomplish this, you will use the most common application of an access list by 
applying it with an IP access group. 


Access groups are used to apply an access list to an interface. When you configure an access 
group, it is applied in an in or out fashion. The in or out options represent how the access list 
will be applied from the perspective of the interface. out applies the access list to all outgoing 
packets, whereas in applies the access list to all incoming packets. The out option will not filter 
packets that originate on the router itself. As mentioned previously, if no access list is defined, 
when an access group is applied to an interface, the default action of the router is to filter all 
traffic. You can apply only one outbound and one inbound access list per interface. 


Use the following command to apply an access list to an interface on a router: 
ip access-group x {in | out } 


Example 14-6 illustrates the commands needed to accomplish denying the 172.16.1.0/24 subnet 
access to the Token Ring. 


Example 14-6 Controlling Network Access with Standard IP Access Lists 


paine#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
01:42:01: %SSYS—-5-CONFIG_I: Configured from console by console 
paine (config) #taccess-—list 5 deny 172.16.1.0 0.0.0.255 

paine (config) #access—list 5 permit any 

paine (config) #int tol 

paine(config—if) #ip access-group 5 out 

paine(config-if) #*2 
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Extended IP Access Lists 


Extended IP access lists apply the same concepts that you just learned; however, they have much 
more control over whether to filter off a source and destination address, along with IP protocol 
type filtering. The general syntax for extended IP access lists is shown here: 


access-list {100-199 | 2000-2699} {permit | deny} protocol_type Source_address 
Source_address_wildcard destination_address destination_address_wildcard 
[protocol specific options] [precedence precedence] [tos tos] [log] [established] 


The access list range is 100 to 199 and has an extended range of 2000 to 2699 in Cisco |OS 
Release 12.0.0 and later. The protocol_ type keyword is a special value that will cause the access 
list to look for a match in the Protocol field of the IP header. Table 14-2 lists the values as of Cisco 
10S Release 12.0. 


Table 14-2. Extended IP Access List protocol type Values for Cisco 1OS 
Release 12.0 


Value | What It Means 
<0-255> [An 1!P protocol number 


<a [Authentication Header Protocol = ssi—i—sSSCs Header Protocol 
— Cisco's EIGRP routing protocol 
a Security Payload 
Cisco's GRE tunneling 
Internet Control Message Protocol 
Internet Gateway Message Protocol 
Cisco's I|GRP routing protocol 


Any Internet protocol 
IP in IP tunneling 


KA9Q [IKA9Q NOS-compatible IPover |Ptunneling = | [IKA9Q NOS-compatible IPover |Ptunneling = | IP over IP tunneling 


OSPF routing protocol 
Payload Compression Protocol 


[Protocol Independent Multicast == sss [Protocol Independent Multicast == sss Multicast 


[Transmission Control Protocol 


User Datagram Protocol 


As you can see, the protocol_type field grows with every release of Cisco |OS Software. Specifying 
the protocol type can be a simple way to avoid complex filters. For example, specifying the 
protocol type when filtering routing protocols such as IGRP, EIGRP, and OSPF instead of filtering 
by the individual IP multicast messages that these routing protocols use can simplify your 
configuration when using the protocol_type keyword. Table 14-3 lists the currently supported TCP 
port numbers under Cisco |OS Release 12.0. 


965 


Table 14-3. Extended IP Access List TCP Port Numbers Supported Under 


Value 
<0-65535> 


telnet 
Time 
Uucp 
Whois 
www 


Cisco IOS Release 12.0 


| What It Means 


Port number 
Border Gateway Protocol (179) 
[Character generator (19) 


Remote commands (rcmd, 514) 


[Domain Name Service (53) 
= (7) 

Exec (rsh, 512) 

Finger (79) 

File Transfer Protocol (21) 
a data connections (used infrequently, 20) 
Gopher (70) 

NIC host name server (101) 
— Protocol (113) 

[ nternet Relay Chat (194) 
Kerberos login (543) 


Kerberos shell (544) 
Login (rlogin, 513) 


[Printer service (515) 

Network News Transport Protocol (119) 
: M Auto-RP (496) 

[Post Office Protocol v2 (109) 

Post Office Protocol v3 (110) 


[Simple Mail Transport Protocol (25) 
[Sun Remote Procedure Call (111) 


Syslog (514) 
TAC Access Control System (49) 


Talk (517) 


UNI X-to-UNIX Copy Program (540) 


INicname (43) 


World Wide Web (HTTP, 80) 


Table 14-4 lists the currently supported UDP port numbers under Cisco |OS Release 12.0. 
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Table 14-4. Extended IP Access List UDP Port Numbers Supported Under 
Cisco 1OS Release 12.0 


What It Means 


Port number 


Biff (mail notification, comsat, 512) 


Bootstrap Protocol (BOOTP) client (68) 
Bootstrap Protocol (BOOTP) server (67) 
Discard (9) 


DNSIX security protocol auditing (195) 


‘Domain Name Service (DNS, 53) 

Echo (7) 

[ nternet Security Association and Key Management Protocol (500) 
mobile-ip [Mobile IP registration (434) 

nameserver 1EN116 name service (obsolete, 42) 


egies NetBIOS datagram service (138) 
gm 


netbios-ns NetBIOS name service (137) 
netbios-ss [NetBIOS session service (139) 


ntp Network Time Protocol (123) 
pim-auto-rp {PIM Auto-RP (496) 


rip [Routing Information Protocol (router, in.routed, 520) 


snmp Simple Network Management Protocol (161) 
snmptrap ISNMP Traps (162) 

sunrpc Sun Remote Procedure Call (111) 

syslog System Logger (514) 


tacacs TAC Access Control System (49) 
talk Talk (517) 


tftp Trivial File Transfer Protocol (69) 
Time (37) 


(Who service (rwho, 513) 


IX Display Manager Control Protocol (177) 


Another enhancement in extended access lists that is not offered by standard access lists is that 
you can specify a match on where traffic originates and where it is destined. At the end of the 
access list, you can set precedence and type-of-service (TOS) values. Here, the router examines 
the IP packet header for these values. The precedence values range from 0 to 7, while the TOS 
values range from 0 to 15. The established keyword is used to check for the ACK or RESET flags 
in the TCP header. If one flag is set, a match occurs. This command is used to pass existing data 
streams through the access list. 


Let's take a look at an extended access list that will be used on a connection to the Internet. In 
this example, an extended access list is configured on the inbound BRI interface to the Internet. 
Figure 14-3 illustrates the network topology for the next example. Sey 


Figure 14-3. Extended Access List Example 


Inbound access list 


access_router 


E0-IP-206.191.241.41/29 


206.191.241.44 


206.191.241.45 


206.191.241.46 


Now, let's add the syntax in Example 14-7 to the access_ router. 


BRIO-IP-206.191.194.42/24 


Example 14-7 Applying an Extended Access List to the access_ router 


access_router (config) #access—list 
access_router (config) #access—list 
access_router (config) #access—list 
206.191.194.42 
access_router (config) #access—list 
access_router (config) #access—list 
access_router (config) #access—list 
access_router (config) #access—list 
access_router (config) #access—list 
domain 
access_router (config) #access—list 
domain 
access_router (config) #access—list 
access_router (config) #access—list 
access_router (config) #access—list 
access_router (config) #access—list 
access_router (config) #access—list 


Now, apply the access list to the BRI interface with the following commands: 


199 
199 
199 


199 
199 
199 
199 
199 


199 


199 
199 
199 
199 
199 


permit 
deny 
deny 


permit 
permit 
permit 
permit 
permit 


permit 


deny 
deny 
permit 
deny 
deny 


tcp any any established 
ip 206.191.241.40 0.0.0.7 any 
ip host 206.191.194.42 host 


icmp any any echo 


icmp any any echo-reply 
206. 
206. 
206. 


tcp 
tcp 
tcp 


udp 


tcp 
tcp 
udp 
udp 
udp 


any 
any 
any 


any 


any 
any 
any 
any 
any 


206. 


206. 
206. 
206. 
206. 
206. 


191 


191 


191 


191. 
.241. 
.241. 
-241 
.241 


191 
191 
191 
191 


.241 
191. 
.241. 


241 


.241. 


241 


40 
- 40 


40 


40 


- 40 


40 
40 


40 
40 


Oo 
° 
° 
“1 


ooo0o°o 
So 6 eG 
oo6 us 
oa 
ad td oo 


eq www 


eq 
eq 


eq 
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smtp 


1024 
1023 
1023 
50000 
1024 


access_router (config) #int bri 0 
access_router(config-if) #ip access-group 199 in 


The first line of the access list in Example 14-6 invokes the established keyword. This keyword 
looks for the ACK or the RESET bits set in the TCP header. This inherently allows existing data 
streams to qualify as a match. The established keyword should be used on any TCP traffic that is 
user-interactive, such as WWW. 


The second line and third lines in Example 14-6 are straightforward. 


In the next subset of lines, you have the following: 


access-list 199 permit tcp any 206.191.241.40 
access-list 199 permit tcp any 206.191.241.40 
access-list 199 permit tcp any 206.191.241.40 
access-list 199 permit udp any 206.191.241.40 


eq www 
eq smtp 

eq domain 
eq domain 


The first entry allows TCP from any source address or network to go to just the subnet of 
206.191.241.40. This would include addresses .41, .42, .43, .44, .45, and .46 only if the TCP port 
is 80 for HTTP or WWW traffic. The second and third lines allow for the same subnet to inbound 
access from Simple Mail Transport Protocol (SMTP), port 25, and POP3 mail, port 110. Finally, we 
have two DNS entries: One allows for DNS that might be operating on TCP port 53, and the other 
allows for DNS, UDP port 53 access, the more common transport for DNS services. 


In the last subset of lines in Example 14-6, you see these lines: 


access-list 199 deny tcp any 206.191.241.40 0.0.0.7 1t 1024 
access-list 199 deny tcp any 206.191.241.40 0.0.0.7 gt 1023 
access-list 199 permit udp any 206.191.241.40 0.0.0.7 gt 1023 
access-list 199 deny udp any 206.191.241.40 0.0.0.7 gt 50000 
access-list 199 deny udp any 206.191.241.40 0.0.0.7 1t 1024 


The first line of this subset of entries denies TCP traffic on ports less than 1024 and from any 
source network to the specific subnet of 206.191.241.40/29. The next line does the same for ports 
greater than 1023. The next line allows UDP ports greater then 1023 to pass, while the last two 
lines deny UDP ports greater then 50000 and deny UDP ports less than 1024. Basically, this subset 
is filtering some of the well-known UDP TCP ports. The implicit deny any would have caught all of 
these ports and the entry may seem redundant; however, sometimes it is desirable to "see" the 
actual ports being denied in the configuration and being logged when someone is trying to access 
them. In this example, you could also filter inclusive ports with a range statement. For example, 
these two lines could be combined into single entry: 


access-list 199 deny tcp any 206.191.241.40 0.0.0.7 1t 1024 
access-list 199 deny tcp any 206.191.241.40 0.0.0.7 gt 1023 


Or: 


access-list 199 deny tcp any 206.191.241.40 0.0.0.7 range 1 65535 


CAUTION 


Enhancements to the access-list commands are backward compatible; migrating 
from earlier releases to Release 11.1 will convert your access lists automatically. 


Releases earlier than Release 11.1 are not upwardly compatible with these 960 


enhancements. If you save an access list with these images later then Release 11.1 
and then use software earlier than Release 11.1, the resulting access list will not be 
interpreted correctly. This can cause severe security problems. 


In other words, access lists from Cisco |OS Releases 11.1 and later are backward and 
forward compatible. Releases earlier than 11.1 are not backward or forward 
compatible. So, your lists run the chances of being destroyed if the router would 
come up under a different Cisco 1|OS Release image or was downgraded somehow. 
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Displaying Access Lists 


By now, you might want to display or troubleshoot your access lists. To view the access lists, 
use the following commands from the enable prompt: 


e show access-list— Displays access lists from all protocols. This command displays 
the number of packets that pass each line of an access list. Use the clear access-list 
counter command to clear these counters. 


e show ip access-list [access-list number]— Displays all 1P access lists defined. If you 
select a specific access list for display, only that list will be displayed. This command 
displays the number of packets that pass each line of an access list. Use the clear 
access-list counter command to clear these counters. 


e show log— This command is used in conjunction with the log keyword trailing any 
access list. Be sure to have a logging buffered command in the configuration to 
capture all the console messages. This message includes the access list number, 
information on whether the packet was permitted or denied, the protocol, and if 
applicable, the source and destination addresses. To prevent huge log files, the router 
generates this message only for the first packet that matches and then at 5-minute 
intervals, including the number of packets permitted or denied in the previous 5- 
minute interval. 


Example 14-8 lists the output of the show ip access-list command. 


Example 14-8 show ip access-list Command Output 


access_router# show ip access-lists 
Standard IP access list 69 
permit 206.191.241.0, wildcard bits 0.0.0.255 log 
Extended IP access list 101 
deny udp host 172.16.16.2 host 204.221.151.211 eq domain 
permit tcp any any established (15992 matches) 
permit ip any 192.168.5.0 0.0.0.255 (43 matches) 
permit ip any 204.221.151.0 0.0.0.255 (169 matches) 
permit icmp any any echo (78 matches) 
permit icmp any any echo-reply (9 matches) 
permit tcp any any eq www (216 matches) 
permit udp any any 
Extended IP access list 110 
permit ip any any (37779 matches) 
permit tcp any any established 
Extended IP access list 199 
permit tcp any any established (175 matches) 
deny ip 206.191.241.40 0.0.0.7 any 
deny ip host 206.191.194.42 host 206.191.194.42 
permit icmp any any echo 
permit icmp any any echo-reply 


permit tcp any 206.191.241.40 0.0.0.7 eq www 
permit tcp any 206.191.241.40 0.0.0.7 eq smtp 
permit tcp any 206.191.241.40 0.0.0.7 eq domain 
permit udp any 206.191.241.40 0.0.0.7 eq domain 
deny tcp any 206.191.241.40 0.0.0.7 1t 1024 
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deny tcp any 206.191.241.40 0.0.0.7 gt 1023 
permit udp any 206.191.241.40 0.0.0.7 gt 1023 (13 matches) 
deny udp any 206.191.241.40 0.0.0.7 gt 50000 
deny udp any 206.191.241.40 0.0.0.7 1t 1024 


access_router# 
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Dynamic Access Lists 


A dynamic access list is an access list that allows temporary access after a user has 
authenticated with the router. For example, in the field, you might want a Cisco engineer 
from the TAC to help you troubleshoot your network by logging into the routers. A dynamic 
access list could be created giving Cisco complete privileges for a predetermined amount of 
time. After a configured time limit expires, the session is closed and traffic is again denied. 
This form of access list is also referred to as lock-and-key security. 


To configure a dynamic access list, you need to perform the following steps: 


Step 1. Define a username and password. 


Step 2. Define the username with the autocommand and timeout arguments; 
these must match a timeout value specified on the dynamic access list. 


Step 3. Define a one-line dynamic access list allowing what traffic you want to pass 
after that user has authenticated. This line also should include the timeout value, 
which must match the one mentioned in the earlier bulleted item. 


Step 4. Define an extended access list, in the same range as the dynamic access list, 
that will serve as the normal packet filter for the interface where you apply it to. This 
must allow Telnet access to the interface it is applied to because this is for Telnet 
authentication. Finally, apply this access list to an interface. 


Step 5. Add the login local port to the vty line numbers; these are displayed by the 
show line command. 


Recalling the same network from the earlier example, you now learn how to clear all the 
access lists and enable any-to-any routing. In Figure 14-4, every router has the 128.200.0.0 


subnet in its routing table, and there is full reachability. 


Figure 14-4. Dynamic Access List Example 


washington EQIP 172 162. v8 henry 


Et-IP 172. 16.2 404 


TRI. DR e116 


973 


In this example, you will define a dynamic access list on the router paine Ethernet 0 port. 
You will allow only users on the 172.16.1.0/24 subnet to authenticate, and then you will 
allow them access to the full 128.200.0.0 subnet. The access list will prevent any packets 
from unauthenticated users from entering into the interface. After someone has 
authenticated, you will allow all the devices on subnet 172.16.1.0/24 access for five minutes 
before closing the dynamic access list. 


First, add a username and password needed for authentication: 


username franklin password ben 
username franklin autocommand access-enable timeout 5 


The second line states that a special autocommand will be run when user franklin logs in. 
access-enable is a special command that will not be displayed by the question mark 
(context-sensitive help)—yes, you will have to remember this one! The timeout value is an 
idle timeout—in this case, it is set for five minutes. This means that the access list will close 
after no traffic has been detected for five minutes. 


Next, define the dynamic access list: 


access-list 101 dynamic allowben timeout 5 permit ip 172.16.1.0 0.0.0.255 any 
access-list 101 permit tcp 172.16.1.0 0.0.0.255 host 172.16.1.2 eq telnet 


The name for the access list must be unique and can be set to anything. What is important is 
the timeout value, which is an absolute timeout value. If you use both timers, either they 
must be equal or the idle timeout must be less than the absolute timeout value. The rest of 
the access list will allow IP traffic the subnet 172.16.1.0/24 access to any network, after 
authenticated. 


The following list provides some Cisco rules and recommendations for configuring dynamic 
access list timers: 


e Either define an idle timeout now with the timeout keyword in the access-enable 
command in the autocommand command, or define an absolute timeout value later 
with the access-list command. You must define either an idle timeout or an 
absolution timeout; otherwise, the temporary access list entry will remain configured 
indefinitely on the interface (even after the user has terminated the session) until the 
entry is removed manually by an administrator. 

e If you configure an idle timeout, the idle timeout value should be equal to the dialer- 
idle timeout value. 

e I!f you configure both idle and absolute timeouts, the idle timeout value must be less 
than or equal to the absolute timeout value. 


The next line is your normal access list that will always be in place until someone has 
authenticated. This access list must begin with a permit of Telnet to the interface where the 
filter is applied. Without allowing Telnet, the user could never authenticate. In this case, you 
will allow only users on the same subnet of 172.16.1.0/24 to authenticate, while denying all 
other traffic. You can now apply the access list to the Ethernet O port of the paine router. This 
is done with the ip access-group 101 in command under the Ethernet 0 interface. 


Finally, you must enable Telnet access under the vty ports, along with the appropriate enable 
passwords. See Chapter 1 if you need additional help with absolute line numbers. Example 
14-9 lists the configuration of the paine router. 
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Example 14-9 paine Router Configuration 


hostname paine 
! 
enable password 7 02050D480809 
! 
username franklin password 7 02040155 
username franklin autocommand access-enable timeout 5 
| 
! 
interface Ethernet0O 
no ip address 
shutdown 
media-type 10BaseT 
! 
interface Ethernetl 
ip address. 172..16.1.2:.255.255..255...0 
ip access-group 101 in 
media-type 10BaseT 
! 
<<<text omitted>>> 
| 
interface TokenRingl 
ip addréss:: 126.200.1212 255.255.2550 
ring-speed 16 
! 
router eigrp 2001 
network 128.200.0.0 
network 172.16.0.0 
no auto-summary 
! 
ip classless 
! 
access-list 101 dynamic allowben timeout 5 permit ip 172.16.1.0 0.0.0.255 any 
access-list 101 permit tcp 172.16.1.0 0.0.0.255 host 172.16.1.2 eq telnet 
! 
! 
line con 0 
line aux 0 
line vty 0 4 
login local 
| 


end 


To test the configuration, either attach a workstation to the Ethernet segment of 
172.16.1.0/24 or use the washington router. The router will always use the address closest 
to the destination for the source address of IP packets. If you want to source a Telnet session 
from a different port, use the following command: 


ip telnet source-interface interface_name 


Example 14-10 first illustrates an unsuccessful ping from washington to jefferson. The user 
then authenticates with paine, followed by successful pings to jefferson. After five minutes, 
the router paine will close the temporary hole and deny future access inbound to its Ethernet 


port. Notice how the Telnet session is immediately closed after authentication—this is normal 
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operation. 


Example 14-10 Testing the Dynamic Access List 


washington# 
washington#ping 128.200.1.5 


Typ scape sequence to abort. 

Sending 5, 100-byte ICMP Echos to 128.200.1.5, timeout is 2 seconds: 
Us UeU 

Success rate is 0 percent (0/5) 


washington# 

washington# 
washington#telnet 172.16.1.2 
Trying 172.162.1662 «.« Open 


User Access Verification 


Username: franklin 

Password: 

[Connection to 172.16.1.2 closed by foreign host] 
washington# 

washington# 

washington#ping 128.200.1.5 


Typ scape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 128.200.1.5, timeout is 2 seconds: 


Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms 
washington# 

<<<After 5 minutes expires>>> 

washington#ping 128.200.1.5 


Typ scape sequence to abort. 

Sending 5, 100-byte ICMP Echos to 128.200.1.5, timeout is 2 seconds: 
Ue. U 

Success rate is 0 percent (0/5) 

washington# 
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Named Access Lists 


With the introduction of Cisco |OS Release 11.2, Cisco introduced a way to label access lists 
with unique names. Named access lists allow the use of descriptive names for an access list 
versus the less descriptive use of numbers. This can be beneficial to network administrators 
using large numbers of access lists. 


To configure a named access list, first define the access list as standard or extended, with the 
following command: 


ip access-list {standard | extended} access_list_name 


After this line is entered, the router prompts you for the next entries under the access list. The 
syntax offered for standard access lists at the access list prompt is shown here: 


{permit | deny} a.b.c.d [wildcard_mask] 


The syntax offered for an extended access list is as follows: 


{permit | deny} protocol_type source_address source_address_wildcard 
destination_address destination_address_wildcard [protocol specific options] {log} 


All the same rules and syntax apply to both cases, except for the access list number preceding 
each line, as in a normal access list. Figure 14-5 illustrates a simple named access list applied to 


an Ethernet interface. 


Figure 14-5. Named Access List Example 


screening_router 


Inbound IP packet 
source IP=172.12.1.100 
Dest IP=172.16.1.100 
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In the example in Figure 14-5, a named access list called allow_net_172 was applied to the 


Ethernet 0/0 port. The command for attaching an access list to an interface is the access- 
group command, which uses the name of the access list instead of numbers. 
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Lab 29: Configuring Access Lists, Named Access Lists, and EIGRP 
Route Filters—Part | 


Practical Scenario 


This chapter has stressed the importance of understanding access lists in binary. This exercise 
underscores this fact. In the field, you will want to make your access lists as small and efficient as 
possible. 


Lab Exercise 


The State Patrol and the County Sheriff use a national fingerprinting system at FBI headquarters. 
Because of the enormous growth in access and use of the system, the FBI wants to cut down on 
the number of networks that it can see and reach. The bureau has implemented a policy that they 
will route only to the even subnets for the State Patrol locations and only to the odd subnets for 
the County Sheriff locations. Because the State Patrol and the County Sheriff have overlapping 
subnets, extreme care must be taken when implementing this policy. Use the following 
parameters as your design guidelines: 


e EIGRP is the routing protocol for this entire network. The autonomous System ID is 2001. 

e Control routing updates so that the FBI router routes receive only even subnets from the 
State Patrol router and odd subnets from the County Sheriff router. 

e The two clouds represent IP networks that the router is attached to. These clouds will be 
simulated by creating a route generator. 

e Use named access lists. 


Lab Objectives 
e Configure the network as depicted in Figure 14-6. Use EIGRP as the routing protocol. 


Figure 14-6. National Fingerprinting System—WAN Access 
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e Allow only routing updates in which the subnet is an even number to be advertised from 
the state_patrol router. Allow only routing updates in which the subnet is an odd number 
to be advertised from the county_ sheriff router. 

e Construct your access list with as few lines as possible. 

e Check the network by issuing a trace from the fbi_hq router to the addresses 
150.100.2.1, which should go to the state_patrol router. Also verify proper route 
advertisement by observing what routers report what routes. 


Equipment Needed 


e Three Cisco routers. The routers should be connected through V.35 back-to-back cables or 
in a similar manner. 


e One LAN segment, provided through hub or switch. 


Physical Layout and Prestaging 


Connect the hubs and serial cables to the routers, as shown in Figure 14-6. 

e Simulate a LAN segment, as shown in Figure 14-6. 

e Configure route generators on the state_patrol and county_ sheriff routers. Do this by 
configuring 10 loopback addresses on the routers; use the same range for both routers— 
150.100.1.0/24 through 150.100.10.0/24. 

e Use EIGRP as the routing protocol. 
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Lab 29: Configuring Access Lists, Named Access Lists, and 
EIGRP Route Filters—Part II 


Lab Walkthrough 


After completing the physical installation, you should establish IP connectivity among all the 
routers. At this point, don't be concerned about pinging loopback addresses of the routers. 
There will be a routing loop until the filters are applied. 


Beginning with the fbi_router router, configure the IP addresses of Ethernet and two Serial 
interfaces. Because you are configuring the DCE side of both links, be sure to include the 
clock rate command under the serial interface. Configure the state_patrol router first. When 
you can ping the serial interface of the fbi_hq router from the state_patrol router, configure 
EIGRP. Seeing individual subnets will be important, so you will need to add the no auto- 
summary command under EIGRP. To configure the state_patrol router as a route generator, 
use MS Notepad and make a file similar to the following: 


int loop 20 

ip add 150.100.1.1 255.255.255.0 
int loop 21 

ip add 150.100.2.1 255.255.255.0 
int loop 22 

ip add 150.100.3.1 255.255.255.0 
int loop 23 

ip add 150.100.4.1 255.255.255.0 
int loop 24 

ip add 150.100.5.1 255.255.255.0 
int loop 25 

ip add 150.100.6.1 255.255.255.0 
int loop 26 

ip add 150.100.7.1 255.255.255.0 
int loop 27 

ip add 150.100.8.1 255.255.255.0 
int loop 28 

ip add 150.100.9.1 255.255.255.0 
int loop 29 

ip add 150.100.10.1 255.255.255.0 


Cutting and pasting this text will be quicker than performing the manual key-ins. When you 
are finished and can see the routes on the fbi_hq router, proceed to configure the 

local_ sheriff router in the same manner. When you are finished, the routing table of the 
fbi_hq router should appear like Example 14-11. 


Example 14-11 show ip route Command on fbi_ hq Router 


fbi_hq# show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M —- mobile, B - BGP 
D — EIGRP, EX -— EIGRP external, O -— OSPF, IA —- OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U -— per-user static route, o — ODR 
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Gateway of last resort is not set 


150.10.0.0/24 is subnetted, 1 subnets 


Cc 150.10.1.0 is directly connected, Ethernet0O 
150.100.0.0/16 is variably subnetted, 12 subnets, 2 masks 

@ 150.100.100.0/30 is directly connected, Serial0d 

e 150.100.101.0/30 is directly connected, Seriall 

D 150.100.2.0/24 [90/2297856] via 150.100.100.1, 00:00:07, Serialod 
[90/2297856] via 150.100.101.1, 00:00:07, Seriall 

D 150.100.3.0/24 [90/2297856] via 150.100.100.1, 00:00:07, Serial0d 
[90/2297856] via 150.100.101.1, 00:00:07, Seriall 

D 150.100.1.0/24 [90/2297856] via 150.100.100.1, 00:00:07, Seriald 
[90/2297856] via 150.100.101.1, 00:00:07, Seriall 

D 150..100:..6.0/24 [90/2297856] via 150:.100.100.1, 00:00<¢07, Seriald 
[90/2297856] via 150.100.101.1, 00:00:07, Seriall 

D 150.100.7.0/24 [90/2297856] via 150.100.100.1, 00:00:07, Serial0d 
[90/2297856] via 150.100.101.1, 00:00:07, Seriall 

D 150.100.4.0/24 [90/2297856] via 150.100.100.1, 00:00:08, Serial0d 
[90/2297856] via 150.100.101.1, 00:00:08, Seriall 

D 150.100.5.0/24 [90/2297856] via 150.100.100.1, 00:00:08, Serial0d 
[90/2297856] via 150.100.101.1, 00:00:08, Seriall 


D 150.100.10.0/24 [90/2297856] via 150.100.100.1, 00:00:08, Serial0d 
[90/2297856] via 150.100.101.1, 00:00:08, Seriall 


D 150.100.8.0/24 [90/2297856] via 150.100.100.1, 00:00:09, Serial0O 
[90/2297856] via 150.100.101.1, 00:00:09, Seriall 
D 150.100.9.0/24 [90/2297856] via 150.100.100.1, 00:00:09, SerialO 
[90/2297856] via 150.100.101.141, 00:00:09, Seriall 


Notice that both route generators are advertising the same routes to the fbi_hq router. If you 
performed only a ping, you might be persuaded to believe that everything was okay. But 
performing a source trace from the Ethernet interface of the fbi_hq router shows that you 
have a routing issue. Example 14-12 lists the output from a source trace and ping. 


Example 14-12 trace and ping Commands from fbi_ hq 


fbi_hq# ping 150.100.1.1 


Type escape sequence to abort. 

Sending 5, 100-byte ICMP Echos to 150.100.1.1, timeout is 2 seconds: 
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms 
fbi_hq# trace 

Protocol (ipl: 

Target IP address: 150.100.1.1 

Source address: 150.10.1.1 

Numeric display [n]: 

Timeout in seconds [3]: 

Probe count [3]: 

Minimum Time to Live [1]: 

Maximum Time to Live [30]: 

Port Number [33434]: 

Loose, Strict, Record, Timestamp, Verbose[none]: 

Typ scape sequence to abort. 

Tracing the route to 150.100.1.1 
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1 150.100.100.1 4 msec 
150.100.101.1 4 msec 
150.100.100.1 8 msec 


Focusing on the state_patrol router, you need to write a named access list that will allow only 
the even subnets to be advertised to the fbi_hq router. These subnets would be 0, 2, 4, 6, 8, 
and 10 of the 150.100.0.0 network. If you wrote 1 through 10 in binary, you would have the 
following: 


0000 0001 = 1 
0000 0010 = 2 
0000 0011 = 3 
0000 0100 = 4 
0000 0101 =5 
0000 0110 = 6 
0000 0111 =7 
0000 1000 = 8 
0000 1001 =9 


0000 1010 = 10 


Notice that all the even subnets have a 0 in the first bit from the right. Therefore, tell the 
access list that the third octet must have a 0 in the first position. Example 14-13 shows how 
to configure the access list with these parameters. The wildcard mask is 0.0.254.255 because 
you want to match on the 0 in the first position on the third octet of the first part of the 
access list. 


Example 14-13 Named Access List to Allow Even Subnets 


state_patrol(config)#ip access-list standard alloweven 
state_patrol (config-std-nacl) #permit 150.100.0.0 0.0.254.255 
state_patrol (config-std-nacl) #exit 

state_patrol (config) #router eigrp 2001 

state_patrol (config-router) #distribute-list alloweven out s0 
state_patrol (config-router) #*Z 


Moving on to the local_ sheriff router, you need to perform a similar exercise. Here, you want 
to allow only the odd subnets to pass to the fbi_hq router. Using the same logic as for the 
access list in Example 14-13, put a 1 in the first position of the third octet of the source 
address of the access list. You can use the same wildcard mask, stating that the first bit must 
be 1 in the third octet, by using the mask of 0.0.254.255. Example 14-14 demonstrates the 
configuration of the local_ sheriff router. 
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Example 14-14 Named Access List to Allow Odd Subnets 


county_sheriff (config) #ip access-list standard allowodd 
county_sheriff(config-std-na) #permit 150.100.1.0 0.0.254.255 
county_sheriff (config-std-na) #exit 

county_sheriff (config) #router eigrp 2001 

county_sheriff (config-router) #distribute-list allowodd out s0 
county_sheriff (config-router) #*Z 

county_sheriff# 


To test the final configurations, go to the fbi_hq router and perform a show ip route and 
source trace. Example 14-15 lists the output from the fbi_hq router. Notice that only the 
even subnets are being reported from 150.100.100.1 in through interface Serial 0. The odd 
subnets are now coming from 150.100.101.1 in through interface Serial 1. 


Example 14-15 show ip route and trace Commands on fbi_ hq Router 


fbi_hq# show ip route 


Codes: C —- connected, S - static, I - IGRP, R - RIP, M —- mobile, B - BGP 
D —- EIGRP, EX —- EIGRP external, O - OSPF, IA —- OSPF inter area 
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
i - IS-IS, Ll - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
U - per-user static route, o —- ODR 


Gateway of last resort is not set 


150.10.0.0/24 is subnetted, 1 subnets 


: 150.10.1.0 is directly connected, Ethernet0 

150.100.0.0/16 is variably subnetted, 12 subnets, 2 masks 
C 150.100.100.0/30 is directly connected, Serial0d 
Cc 150.100.101.0/30 is directly connected, Seriall 
D 150.100.2.0/24 [90/2297856] via 150.100.100.1, 00:01:35, Serial0O 
D 150.100.3.0/24 [90/2297856] via 150.100.101.1, 00:01:30, Seriall 
D 150.100.1.0/24 [90/2297856] via 150.100.101.1, 00:01:30, Seriall 
D 150.100.6.0/24 [90/2297856] via 150.100.100.1, 00:01:35, Serial0d 
D 150.100.7.0/24 [90/2297856] via 150.100.101.1, 00:01:30, Seriall 
D 150.100.4.0/24 [90/2297856] via 150.100.100.1, 00:01:35, Serial0d 
D 150.100.5.0/24 [90/2297856] via 150.100.101.1, 00:01:30, Seriall 
D 150:100.10.0/24. [90/2297856] via 150.100.200.121, 00:01:35; Seriald 
D 150.100.8.0/24 [90/2297856] via 150.100.100.1, 00:01:35, Serial0d 
D 150.100.9.0/24 [90/2297856] via 150,1200.,101.1;, 00701:31, Seriall 
fbi_hq# 


fbi_hq#trace 

Protocol [ip]: 

Target IP address: 150.100.1.1 
Source address: 150.10.1.1 
Numeric display [n]: 

Timeout in seconds [3]: 

Probe count [3]: 

Minimum Time to Live [1]: 
Maximum Time to Live [30]: 
Port Number [33434]: 

Loose, Strict, Record, Timestamp, Verbose[none]: 
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Typ scape sequence to abort. 
Tracing the route to 150.100.1.1 


1 150.100.101.1 0 msec 0 msec * 
fbi_hq# 


Example 14-16 shows the complete configuration for the state_patrol, county_ sheriff, and 
fbi_hq routers. 


Example 14-16 Complete Configurations for state_ patrol, 
county_ sheriff, and fbi_hq Routers 


hostname state_patrol 
! 


ip subnet-zero 

! 

interface Loopback20 

ip address: 150.100.1.1 255.255.2550 
no ip directed-broadcast 

! 

interface Loopback21 

ip addréss: 150.100.2.1 255.255.255.0 
no ip directed-broadcast 

! 

interface Loopback22 

ip address: 150;100.3.1. 255.255.2550 
no ip directed-broadcast 

! 

interface Loopback23 

ip address: 150.100.4)..1 255.255.255..0 
no ip directed-broadcast 

! 

interface Loopback24 

ip address 150.100.5.1 255.255.2550 
no ip directed-broadcast 

! 

interface Loopback25 

ip address 150.100.6.1 255.255.2550 
no ip directed-broadcast 

! 

interface Loopback26 

ip address 150:,100.7.1 255.255.2550 
no ip directed-broadcast 

! 
interface Loopback27 

ip address 150.100.8.1 255.255.255..0 
no ip directed-broadcast 

! 
interface Loopback28 

ip address: 150:.:100, 9.1 255.255.2550 
no ip directed-broadcast 

! 
interface Loopback29 

ip address 150.100.1031 255.255...255 ..0 


no ip directed-broadcast 
! 
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<<<text omitted>>> 
i} 


interface SerialO 


ip address 150.100..100.1255.255.255.252 


no ip directed-broadcast 
! 


<<<text omitted>>> 

! 

router eigrp 2001 

network 150.100.0.0 

distribute-list alloweven out Serial0O 
no auto-summary 

! 

ip access-list standard alloweven 
permit. 150.100.0.0 0.0.254.255 


hostname county_sheriff 
I 
ip subnet-zero 
! 
interface Loopback20 
ip address: 150.100. 1...) 255.255.255..:0 
no ip directed-broadcast 
! 
interface Loopback21 
ip address 150..100.2.1 255.255.2550 
no ip directed-broadcast 
! 
interface Loopback22 
ip address 150,100.31 255.255.2550 
no ip directed-broadcast 
! 
interface Loopback23 
ip address 150.100.4.1 255.255.255.0 
no ip directed-broadcast 
! 
interface Loopback24 
ip addréss 150,100.51 255.255.2550 
no ip directed-broadcast 
! 
interface Loopback25 
ip addréss:.150:.100.6.1 255%255.255.0 
no ip directed-broadcast 
! 
interface Loopback26 
ip: address. 150..100..7.1.255.255.255..0 
no ip directed-broadcast 
! 
interface Loopback27 
ip address. 150.100.8.1 255.255.255...0 
no ip directed-broadcast 
! 
interface Loopback28 
ip address 150.100.9.1 255:.255.255...0 
no ip directed-broadcast 
! 
interface Loopback29 
ip address 150;100,10.1 255.255.,255:..0 
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no ip directed-broadcast 
! 


<<<text omitted>>> 
l 
interface Serial0 
ip address: 150.100; 101.1 255.255.259.252 
no ip directed-broadcast 
| 
<<<text omitted>>> 
\ 
router eigrp 2001 
network 150.100.0.0 
distribute-list allowodd out Serial0O 
no auto-summary 
! 
ip access-list standard allowodd 
permit 150.100.1.0 0.0.254.255 


hostname fbi_hq 
! 
interface Ethernet0O 


ip address: 150..10.1.1 255.255 .205.0 
\ 


interface Serial0O 

ip address, 150..100..100.2. 255.255.255.252 
no fair-—queue 

clockrate 2000000 

! 

interface Seriall 

ip address: 150.100.,101.2 255.255.255.252 
clockrate 2000000 

! 
<<<text omitted>>> 

! 

router eigrp 2001 

network 150.10.0.0 

network 150.100.0.0 

no auto-summary 


fbi_hq# 
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Lab 30: Configuring Dynamic Access Lists and Traffic Filters by 
Using Named Access Lists—Part | 


Practical Scenario 


As more networks grow together, either by the Internet or internally, you will be required to 
control access to them. The best way to control access is not to advertise the private subnet with 
a routing protocol. However, IP access might be required at times, so you will have to advertise 
your networks with a routing protocol. To control access on a packet level, you will have to use an 
access list. 


Lab Exercise 


The upstart company of Wavester.com provides secure FTP and TFTP access to its huge MP3 
archive. Many universities were experiencing high and expensive Internet usage. To the delight of 
the students, Wavester now offers direct Tl access to its archives. In this lab, you will configure a 
T1 to the Wavester site. The only protocols that can travel across the link are FTP, TFTP, ping, 
and routing protocols. Place this filter in the most effective location using the following criteria: 


e OSPF is the routing protocol. All new sites are to be configured as stub areas. 

e Control traffic so that only FTP, TFTP, and ping go across the serial link. Allow FTP access 
only to the server 150.10.1.10 from the 132.31.5.16/27 subnet. 

e Use named access lists. 

e Configure an access list that denies Telnet access to graceland until a user authenticates 
with the wavester router. Then allow access only from the 132.31.5.16/27 subnet. 


Lab Objectives 


e Configure the network as depicted in Figure 14-7. Use OSPF as the routing protocol. 
Configure the router jo_college to be in a stub area. 


Figure 14-7. Wavester.com Network 
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Allow only Telnet, FTP, TFTP, ping, and routing protocols to cross the serial link. Allow FTP 
access only to the server 150.10.1.10. 

Configure another access list on wavester that prevents Telnet to the graceland router 
from the 132.31.5.16 subnet. When the user theking with password elvis authenticates 
with wavester, Telnet access from the 132.31.5.16/27 subnet will be allowed into 
graceland. The authentication should expire 10 minutes from login. 


Equipment Needed 


Three Cisco routers. Two of the routers should be connected through V.35 back-to-back 
cables or in a similar manner. 

Two LAN segments, provided through hubs or switches. 

Two workstations for testing FTP, and TFTP file transfers. Use software found at http: // 
download.cnet.com/ for the FTP and TFTP clients and servers. FTP uses different ports to 
send data than it does for its initial connection. Applying your filter to a live FTP client and 
server environment will manifest errors that you will not see without a live connection. 
Remember that the router will source its packets from the closest interface to its 
destination, so workstations are required for proper testing of access lists. 


Physical Layout and Prestaging 


Connect the hubs and serial cables to the routers, as shown in Figure 14-7. 

Simulate the LAN segments, as shown in Figure 14-7. 

Attach a workstation to the Ethernet segment of the wavester router. This workstation will 
serve as the FTP and TFTP server. Attach another workstation to the Ethernet segment of 
the jo_college router to serve as the FTP and TFTP client. You can download network 
utilities from http: //download.cnet.com/. 

The router can also be used to test TFTP, but be aware of where it sources its packets 
from because this will affect where you place your filters. 

Use OSPF as the routing protocol. Place the graceland router and the wavester router into 
Area 0, and put the jo_college router into stub Area 100. Ensure full IP connectivity before 
applying any filters. 


988 


989 


Lab 30: Configuring Dynamic Access Lists and Traffic Filters by 
Using Named Access Lists—Part II 


Lab Walkthrough 


After completing the physical installation, you should establish IP connectivity among all the 
routers. Configure OSPF Area 0 on the Ethernet interface of the graceland and wavester 
routers. Put the serial interface of the wavester into OSPF Area 100. Use the area 100 stub 
command to make jo_college a stub router. When you have full IP connectivity from the 
132.31.5.18 subnet to the 150.10.1.1 subnet, begin to test file transfers. 


Configure a workstation as an FTP and TFTP server on the Ethernet segment of the wavester 
router. Test file transfers with the FTP client software or the router. Ensure that you can 
transfer files back and forth before proceeding to configure filters. You can download network 
utilities from http://download.cnet.com/. 


The first access list to configure goes on the jo_college router. This access list must allow 
Telnet, FTP, OSPF, TFTP, and ICMP through it. Place the access list close to the source of 
traffic that you want to filter, which is the FTP/TFTP client. The named access list should look 


like Example 14-17. 


Example 14-17 IP Named Access List 


ip access-list extended allow_filetrans 

permit tcp any any established 

permit tcp 132.31.5.16 0.0.0.15 any eq telnet 

permit. tep 132.31.5.16 0.0.0.15 host. 150:.10.1.10 eq ftp 
permit, tep. 132.301.5216 0.0.0.15 host 150 210.1210 gt 1023 
permit ospf any any 

permit udp any any eg tftp 

permit icmp any any echo 

permit icmp any any echo-reply 


The first line of the access list allows established connections or connections with the ACK or 
RST bits set in the TCP header to pass. The second line allows Telnet access from the subnet 
of 132.31.5.16 to anywhere. The wildcard mask in the second line is derived from laying out 
the .16 subnet in binary and looking at the significant bits. If you want to allow the hosts only 
on the .16 subnet, you need to match on the first 4 bits in the fourth octet. 


0001 0000 = subnet 16 


0000 1111 = wildcard mask = 15 


Therefore, the wildcard mask of 0.0.0.15 will allow hosts on subnet 132.31.5.16/27 to pass. 


The next three lines are used for FTP access: 


permit tcp 132.31.5.16 0.0.0.15 host 150.10.1.10 eq ftp 
permit tcp 132.31.5.16 0.0.0.15 host 150.10.1.10 gt 1023 
permit tcp host 150.10.1.10 132.31.5.16 0.0.0.15 gt 1023 
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FTP initiates a session from the client to the server on TCP port 21, but it sends data on 
random ports above 1023. It is a common misconception that FTP uses TCP port 20 to send 
data. When configuring an access list for FTP, you must allow TCP ports greater than 1023. 


The next line in the access list allows OSPF packets, while the following line allows UDP equal 
to port 69, TFTP. Another common pitfall when writing access lists is to filter the routing 
protocol. Of course, when this happens, all the routes in the routing table disappear, thereby 
making it an easy error to spot. 


Finally, the last two lines allow ICMP echo and echo-reply. These lines enable you to still ping 
the remote routers. Apply the filter to the Ethernet interface with the following command: 


ip access-group allow_filetrans in 


After the access list is applied, try to transfer files to and from the FTP/TFTP server. A live 
test of the application is the only way to properly test any type of traffic filters. 


The next step in the lab is to configure a dynamic access list on the wavester router. This 
access list must allow Telnet to this router while denying Telnet access to the graceland 
router. When the user theking authenticates, Telnet access is granted to graceland for 10 
minutes. The access list to accomplish this looks like Example 14-18. 


Example 14-18 Dynamic Access List on wavester 


ip access-list extended allowtelnet 

dynamic allowking timeout 10 permit tcp 132.31.5.16 0.0.0.15 host 150.10.1.1 eq 
telnet 

permit. tep 132.31.5.16 0.0.0.15 host 150.101.100.2 eq telnet 

deny tcp any host 150.10.1.1 eq telnet 

permit ip any any 


The first line of the access list is a dynamic command that permits Telnet from the 
132.31.5.16/27 subnet to the specific host address of 150.10.1.1. When a user authenticates, 
this access list stays open for 10 minutes. The next line allows Telnet access to the Serial 
interface of the wavester router, which is needed for authentication to take place. The next 
line is the line that denies Telnet access from anywhere to the graceland router's Ethernet 
port. Finally, the last line of the access list will permit any IP traffic. The access list is applied 
to the serial interface with the ip access-group allowtelnet in command. 


The second part of configuring a dynamic access list is to configure a username, password, 
and autocommand. The autocommand timeout value must match what is used in the 
dynamic line of the access list, if you are using both timeouts. Example 14-19 shows the 


username combinations on the wavester router. 


Example 14-19 Username Passwords for Dynamic Access Lists 


username theking password elvis 
username theking autocommand access-enable timeout 10 


Before testing the configuration for Telnet access, be sure to configure the routers' vty 
sessions to support Telnet. To test the dynamic access list, first try to Telnet to the graceland 
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router from the jo_college router. The session should be denied. Next, Telnet to the serial 
interface of the wavester router and log in as theking with the password elvis. The session 
should immediately close and jump you back to the jo_college router. Now, Telnet to the 
graceland router, and your login will be accepted. 


Example 14-20 shows the complete configurations for the wavester and jo_college routers. 


Example 14-20 jo_college and wavester Router Configurations 


hostname jo_college 
| 
enable password cisco 
! 
username cisco password 0 cisco 
ip subnet-zero 
f 
<<<text omitted>>> 
| 
interface Ethernet0O 
ip address. 132.321.5217 2554255<255.240 
ip access-group allow_filetrans in 


no ip directed-broadcast 
| 


interface SerialOd 
ip address: 150.100.100.171 255.255.255.252 
no ip directed-broadcast 

' 

<<<text omitted>>> 

| 

router ospf 69 

network 132.31.5.17 0. 
network 150.100.100.1 


area 100 stub 
i) 


0.0.0 area 100 
O. 


ip classless 

1 

ip access-list extended allow_filetrans 

permit tcp any any established 

permit tcp 132.31.5.16 0.0.0.15 any eq telnet 

permit. tep 132.531.5216: 0.0.02:15 host 150210.1.10 eq £tp 
permit tcp 132.31.5.16 0.0.0;15 host. 150.10.1.10 ¢@t 1023 
permit ‘tep host: 150.10.,1.10 132.31,5.26 0.0.0.15 ge 1023 
permit ospf any any 

permit udp any any eg tftp 

permit icmp any any echo-reply 

permit icmp any any echo 

| 


line con 0 

transport input none 
line aux 0 

line vty 0 4 

end 


hostname wavester 

! 

username theking password 0 elvis 

username theking autocommand access-enable timeout 10 
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clock timezone PAC -8 
! 
interface Ethernet0 


ip address: 150.10.1.4 255.2595::255..0 
1 


interface Serial0 

ip address 150..100.100.2 255.2595..259 252 
ip access-group allowtelnet in 

no fair-queue 

clockrate 2000000 

| 
<<<text omitted>>> 

! 
router ospf 69 

network 150.10.1.4 0.0.0.0 area 0 
network 150.100.100.2 0.0.0.0 area 100 
area 100 stub 

| 
ip classless 

! 
ip access-list extended allowtelnet 
dynamic allowking timeout 10 permit tcp 132.31.5.16 0.0.0.15 host 150.10.1.1 eq 
telnet 

permit tcp 132.31.5.16 0.0.0.15 host 150.101.100.2 eq telnet 
deny tcp any host 150.10.1.1 eq telnet 
permit ip any any 

! 

line con 0 

line aux 0 

line vty 0 4 

login local 

! 


end 
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Part Vil: Enhanced Network Protocols 


Chapter 15 Configuring Network Address Translation (NAT) 
Chapter 16 Configuring Hot Standby Routing Protocol (HSRP 
Chapter 17 Configuring Network Time Protocol (NTP) and Simple Network Time Protocol 


(SNTP) 
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Chapter 15. Configuring Network Address Translation 
(NAT) 


The phenomenal growth of the Internet spawned a tremendous squeeze on IP address space. 
Some of the stronger solutions offered to relieve this pressure are classless interdomain 
routing (CIDR) and |Pv6. CIDR can be viewed as the short-term solution until |Pv6 becomes 
the dominant version of IP in use. But many private networks and ISPs have yet to migrate 
to |Pv6. Perhaps one reason for the delay to migrate to |Pv6 is the huge success of an 
intermediate solution called Network Address Translation (NAT). 


NAT allows many private companies and individuals to implement private address space for 
their networks, provided under RFC 1918, thereby conserving valuable public address space. 
NAT also provides ways for addresses in the same routing domain to "overlap" each other yet 
reach the common hosts. The translation of addresses by NAT inherently provides a level of 
security directly needed when transporting data across the Internet. This chapter discusses 
how NAT operates and covers NAT terminology. It also explores the three major 
implementations of NAT—NAT pools, static NAT, and NAT overload. 
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NAT Technical Overview 


RFC 1631, "The Network Address Translator (NAT)," outlines NAT, which is most often installed on 
a router in a stub domain—that is, a network with a single exit point. Specifically, NAT handles two 
types of translations: 


e Outside address translation entry 
e Inside translation entry 


To explain how these translations work, it is important to understand NAT terminology. 
NAT Terminology 


Some terms mentioned earlier apply to all NAT configurations. The term inside refers to networks 
that are private and that reside inside your routing domain. The inside is the address that you will 
be translating. The term outside refers to networks that are "visible" and most often routable to 
the outside world. The term global is used with inside and outside as well; think of the term to 
mean that this address space is assigned by NIC. Table 15-1 details how the words are used 
together. 


Table 15-1. NAT Terminology 


| NAT Term Definition 


Inside local address(s) The IP address(s) assigned to the host(s) on the 
network that is to translate. This network should be 
one of the networks provided by RFC 1918. 


Inside global address(es) |A routable and legitimate IP address, assigned by the 
NIC or ISP. This range must be routable to the 
Internet or destination network(s). 


Outside local address(es) |The IP address of an outside host(s), as it is viewed 


by the inside host(s). This space is reachable from an 
inside network and might or might not be registered 
|1P address space. It is used primarily in static 
translations. 


Outside global address The IP address assigned to a host(s) on the outside 

(es) network; this is routable and visible to Internet. It is a 
registered address and is used primarily in static 
translations. 


NAT processes a packet that originates from an inside network in the following manner: 


1. When NAT receives a packet from an inside interface that passes the criteria set for 
translation, it searches the NAT table for an outside address-translation entry whose outside 
local address is equal to the destination IP address of the packet. 


2. If no match is found in the lookup, the packet is dropped. 


3. If an entry is found, NAT replaces the destination address in the packet with the ote 


global address from the table entry. 


4. NAT proceeds to search the NAT table to see if an inside local address is equal to the source 
IP address in the packet. 


5. If an entry is found, NAT replaces the source address in the packet with the inside global 
address. 


6. If no entry is found, NAT creates a new inside address entry and inserts it in the packet. 


NAT processes a packet that originates from an outside network in the following manner: 


1. When NAT receives a packet that originated from an outside interface that passes the 
criteria set for translation, it searches its address translation table for an entry where the 
inside global address is equal to the destination address of the packet. 


2. If no entry is found, the packet is dropped. 


3. If an entry is found, NAT replaces the destination address with the inside local address from 
the translation table. 


4. The router searches the NAT table for an outside global address that is equal to the source 
IP address of the packet. 


5. If an entry is found, NAT replaces the source address with the outside local address from 
the table entry. 


6. If NAT does not find an entry, it creates one and performs the same task. 


7. Any time NAT modifies the header, the router also needs to recalculate and replace the IP 
and TCP checksums. 


Figure 15-1 shows a workstation on a private network of 172.16.1.0/24 that it is running a TCP 
application that needs to reach a public university network of 128.100.1.0/24. 


Figure 15-1. NAT Translation Example 
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The public network of 128.100.1.0/24 or the UW has no visibility to the private network 
172.16.1.0. However, 172.16.1.0 does have a route to the 128.100.1.0/24 subnet. As a packet 
originates from the host 172.16.1.10 to 128.100.1.10, it will have a source IP address of 
172.16.1.10 and a destination IP address of 128.100.1.10. As the packet enters the NAT inside 
interface (EO) of the NAT router, it is routed through an NAT outside interface, SO. 


When this happens, the router follows a list of user-defined criteria to determine whether address 
translation should take place. This is usually accomplished by checking an access list. If translation 
is to happen, the router translates according to how NAT is configured. This example uses a NAT 
pool of 254 addresses in the 128.100.100.0/24 range. These are the inside global addresses. 


NAT now makes an association table between 172.16.1.10 and 128.100.100.2. It replaces the 
source IP address 172.16.1.10 of the packet with 128.100.100.2 and forwards the packet out its 
SO port. This example uses a loopback interface for a NAT pool; the IP address is 128.100.100.1. 
NAT uses the next available address on this subnet for its association—in this example, it uses 
128.100.100.2. When the UW router receives the packet, it will have appeared to come from the 
subnet 128.100.100.0/24. This network is reachable by this router, and it can service the request. 


On the NAT router, you must have at least one globally reachable |P address; in this example, this 
is referred to as an inside global address. This address or pool of addresses is where NAT replaces 
the original source |P address with a new source IP address specified by NAT. When this packet 
reaches its destination, the host on the other side thinks that the packet comes from the global 
inside address, or the pool. Example 15-1 shows the results of a ping from 172.16.1.10 to 
128.100.1.10. You can see the translations taking place by using the debug ip nat command 
along with the show ip nat translations command. 


Example 15-1 NAT Translation Example 


nat_router#deubg ip nat 


00:17:30: NAT*: s=172.16.1.10—->128.100.100.2, d=128.100.1.10 [4097] 
00:17:30: NAT*: s=128.100.1.10, d=128.100.100.2->172.16.1.10 [4097] 
OOS T7312 NAT*s Ss=L72.16.1.10-5128.100.100.2, d=128.100.1.10 [4353] 
00:17:31: NAT*: s=128.100.1.10, d=128.100.100.2->172.16.1.10 [4353] 
00:17:32: NAT*: s=172.16.1.10->128.100.100.2, d=128.100.1.10 [4609] 
OOsL72322 NAT*: s=128.100.1.10; d=128.100.100.2-5172.16.1.10 [4609] 
OOSL7233%. NAT*? s=172..16.1.10-5128.100.100.2, d=128..100.1..10° [4865] 
O0s17233 NAT*: s=128.100.1.10, d=128.100,100.2=5172.16.1.10 [4865] 
nat_router# 

nat_router#show ip nat translations 

Pro Inside global Inside local Outside local Outside global 
=== 128..100.100.2 V72216.1.10 ae oad 


For reference, this type of NAT is called dynamic translation, and it is discussed in greater detail in 
a later section. Example 15-2 lists the configuration of the nat_router from Figure 15-1. 


Example 15-2 NAT Dynamic Pool Configuration for the nat_ router 


hostname nat_router 
! 
ip subnet-zero 
! 
interface Loopback20 
ip address 128.100.100.1 255.255.255.0 
no ip directed-broadcast 
! 
interface Ethernet0 
ip address 172.16.1.254 255.255.255.0 
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no ip directed-broadcast 
ip nat inside 

J 

interface Serial0O 

ip address 128.100.11.1 255.255.255.252 
no ip directed-broadcast 
ip nat outside 

J 

<<<text omitted>>> 

J 

router eigrp 2001 
network 128.100.0.0 

J 


—_ 
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ip nat inside source list 69 pool publicpool 
ip classless 

! 

access-list 69 permit 172.16.1.0 0.0.0.255 

! 
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NAT and RFC 1918 


Many of the benefits of NAT are derived from the goal of conserving public |1P address space. 
As you can see from the preceding example, NAT allows you to have private addressing while 
accessing services outside your routing domain. RFC 1918, "Address Allocation for Private 
Internets," sets aside ranges of addresses that ISPs will not forward. This allows for the 
design of many internetworks capable of accessing Internet services without having to worry 
about having registered addresses. Specifically, RFC 1918 reserves the IP address ranges 
listing in Table 15-2. 


Table 15-2. 1P Address Range for RFC 1918 


| IP Address Class | IP Address Range 
Class A [10.0.0.0 tO.20 .255:2599,295 

ae B |172.16.0.0 tO:172:31:255,.255 
Class C [192.168.0.0 to 192.168.255.255 


NOTE 


When using private address space, use it wisely. Unfortunately, many network 
designs have implemented using the 10s network with 24-bit mask on point-to- 
point links, 16-bit masks on Ethernet segments, and so on. J ust because the 
address space is vast, don't let this lead to sloppy IP address schemes. 
Remember that proper subnetting helps with route summarization and route 
propagation, both of which can have a significant impact on large internetworks. 
Many internetworks are also built around the 10s subnet. In the few years that 
this RFC has been out, many networks have merged and have had address 
overlaps on the 10s subnet, while the thousands of networks that reside on the 
172.16.0.0 remain unused. My point again is to use this space wisely; treat it as 
you would if the address spaces were registered. Be original in your design. You 
will find that the little extra time you take in proper IP design will benefit you 
immensely as your internetwork scales and grows together with other 
internetworks. 
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Configuring NAT 


NAT translation can be configured in three primary ways: 


e Dynamic translation— NAT translates inside addresses to a pool of global 
addresses. After a period of time, the translation times out and global address goes 
back to the pool to be reused. The timeout value for all NAT translations is based on 
protocol. The timeout values are listed in the later section "Clearing and Changing 


NAT Translations." 


e Static translation— NAT uses a one-for-one address mapping. This allows the 
outside network to initiate a session to the inside network based on the NAT address. 


e Overload of a single IP address— This involves multiplexing addresses in which 
many local |P addresses use port address translation (PAT) to share a single global IP 
address. 


All three methods of configuration follow a similar four-step process: 


Step 1. Define NAT inside and outside networks. First, define what networks are to be 
translated. You might not want all inside networks to be translated. Also note where 
they reside from your router's perspective, and mark that interface as a NAT inside 
interface. Second, locate the exit point of your routing domain, where the destination 
networks exist; usually this is the Internet. Configure this exit interface as a NAT 
outside interface. You can have multiple inside and outside interfaces. These steps are 
accomplished using the ip nat inside and ip nat outside commands at the interface 
or subinterface prompts. 


Step 2. Ensure that IP reachability exits between the destination network/ Internet 
and the address/pool that you are translating to. If you are configuring a dynamic or 
static translation, you must ensure that the outside network can reach the subnet of 
your inside global network. The inside global network is the network that you are 
translating your addresses into. Put the subnet of the global address on a loopback 
interface, and ensure that the subnet is propagated via a routing protocol or a static 
route. This is to ensure that the subnet is reachable from the outside network. 


Step 3. Configure the specific networks that are to be translated. If you are 
configuring dynamic NAT pools, this step is accomplished with the following command: 


ip nat inside source [list {1-99} | route-map] pool pool_name 
overload 


Use an access list or a route map to match the networks that will be translated. Take 
into account all networks that might pass through the interface, not just the local 
network. The pool argument defines what pool will be used for translation. The 
overload argument enables the router to use one global address for many local 
addresses. 


If you are configuring static translation, use the following command: 
ip nat inside source static local_ip_addr global_ip_addr 
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Step 4. Configure the address pool. This step is covered in Step 3 if you are using a 
static translation. When using dynamic translation, first "anchor" the global subnet to 
a loopback address. For example, if you are translating to the subnet of 
150.100.100.0/24, put this subnet on a loopback address instead of using a 
secondary IP address on a "real" interface. This way, NAT will work on multiple 
interfaces if one goes down. This also prevents potential routing issues on IP 
secondary interfaces. To define the pool, use the following command: 


ip nat pool pool_name starting_ip_addr ending_ip_addr {netmask 
netmask | prefix-length prefix-length} 


Configuring NAT Dynamic Translation 


Using the four-step process listed, now you will walk through the NAT configuration that you 
did earlier in this chapter. Figure 15-2 illustrates a private IP network of 172.16.1.0/24. 


Figure 15-2. Dynamic NAT Example 
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This network needs reachability to the Internet—specifically, the host 128.100.1.10 on the 
UW Ethernet segment. The router nat_router has a T1 connection to the Internet through the 
isp_router. The ISP has assigned the network 128.100.100.0/24 to nat_router for access to 
the Internet. The engineers who support nat_router do not want to change all the IP host 
addresses from a 172.16.1.x network to a 128.100.100.x network, so they use dynamic NAT. 


First, you must define NAT inside and outside networks. The inside network is where the 
networks to be translated reside, while the outside network is your destination network. In 
this example, your EO port will become your NAT inside interface, while your SO port will be 
your NAT outside interface. Figure 15-3 highlights the inside and outside networks. 


Figure 15-3. NAT Inside and Outside Networks 
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To configure the inside and outside interface, use the ip nat [inside | outside] command. 
Example 15-3 demonstrates the use of the command. 


Example 15-3 Configuring Inside and Outside I nterfaces 


nat_router (config) #interface e0 
nat_router(config-if)#ip nat inside 
nat_router (config-if) #exit 
nat_router (config) #interface s0 
nat_router(config-if) #ip nat outside 


The next step requires you to "anchor" the subnet that you are translating to on this router. 
You do this by assigning the network given to you from your |SP—in this case, 
128.100.100.0/24 to a local interface. Use the first host address on the loopback interface, 
and use 128.100.100.2 to 128.100.100.254 as the address pool. The second part of this step 
requires that you have a route to the outside network and that the outside networks have a 
route to the subnet 128.100.100.0/24. For this example, you add a static default route on 
the nat_router and you use the ip classless command, which would appear as follows: 


interface Loopback20 

ip address 128.100.100.1 255.255.255.0 
ip classless 
ip route 0.0.0.0 0.0.0.0 128.100.11.2 


Relevant to this example but not shown is a static route on the isp_router to the subnet 
128.100.100.0/24. This route must be propagated by the isp_router to any and all 
destination networks, such as the uw_router. At this point, before proceeding, ensure that all 
routers have IP reachability to the 128.100.100.0/24 subnet. Without IP reachability, NAT will 
fail. 


The third step in the process is to use the ip nat inside source command to define the 
networks to be translated. In this example, you will use the following commands: 


ip nat inside source list 69 pool publicpool 
access-list 69 permit 172.16.1.0 0.0.0.255 
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This command sequence calls access list 69 and compares the source network of the packet 
coming in the inside interface to the list. If the source IP address is in the subnet range of 
172.16.1.x, the network is translated to the IP pool called publicpool. 


Finally, the last step is defining the pool publicpool using the ip nat pool command: 


ip nat pool publicpool 128.100.100.2 128.100.100.254 netmask 255.255.255.0 


This statement uses the IP address range of 128.100.100.2 to 128.100.100.254, witha 
subnet mask of 255.255.255.0 for translation. Because 128.100.100.1 is the address of the 
loopback address, you do not want to include it in the pool range. Example 15-4 lists the 


relevant portions the configuration of the nat_router. 


Example 15-4 NAT Dynamic Translation Configuration 


hostname nat_router 


ip subnet-—zero 


interface Ethernet0O 
ip address 172.16.1.254 255.255.255.0 
no ip directed-broadcast 


interface Serial0d 
ip address 128.100.11.1 255.255.255.252 
no ip directed-broadcast 


<<<text omitted>>> 


Configuring NAT Static Translation 


Configuring static translation is similar to configuring dynamic translation, except that you do 
not configure an IP pool. Instead, you configure a one-to-one address map of which specific 
hosts are to be translated to a specific address. A static translation can be used as an inside 
static translation or can have an outside static translation. Most implementations of NAT 
simply use an inside static translation, but when NAT is overlapping, you might want to use 
an outside source translation. 


Building on the previous example of NAT illustrated in Figure 15-3, modify it so that only one 
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address, 172.16.1.10, will be translated to 128.100.100.10. To configure static NAT, follow 
the same steps as previously defined, which include defining the inside and outside networks. 
Define the loopback address to "anchor" the global network and ensure routing between this 
subnet, 128.100.100.0/24, and the outside networks. The only part that is different from 
dynamic NAT configuration is defining how networks get translated. Instead of using the ip 
nat inside source list x command, use the ip nat inside static command. Specifically, this 
example uses the following command: 


ip nat inside source static 172.16.1.10 128.100.100.10 


This command causes the address 172.16.1.10 to be mapped to 128.100.100.10. No other 
translations will occur on the router. Example 15-5 lists how the configuration would appear 


with a static configuration. 


Example 15-5 NAT Static Translation Example 


hostname nat_router 
! 


ip subnet-—zero 
! 


interface Loopback20 


no ip directed-broadcast 

! 
interface Ethernet0O 

ip address 172.16.1.254 255.255.255.0 
no ip directed-broadcast 


! 
interface Serial0d 

ip address 128.100.11.1 255.255.255.252 
no ip directed-broadcast 


<<<text omitted>>> 
! 


ip classless 
ip route 0.0.0.0 0.0.0.0 128.100.11.2 


Configuring Easy IP and Port Address Translation (PAT) 


Perhaps "Easy IP" expresses the best example of overloading a single |P address for NAT. 
Easy IP combines NAT overload/PAT and PPP/Internet Protocol Control Protocol (1PCP). 
However, NAT TCP overload is not limited to PPP. 


For the purposes of this text, TCP overload and PAT are synonymous. PAT provides for many- 
to-one IP translations. Essentially, this allows many IP addresses to share or be translated 
into a single IP address. PAT uses a unique source port number on the inside global IP 
address to distinguish between each translation. 


Easy IP (Phase 1) enables a Cisco router to automatically negotiate its own registered WAN 
address, and it enables local hosts to access the global networks or Internet through this 
single IP address. Many ISPs use IPCP to dynamically assign an |P address to the remote 


serial interface. Because this address is unknown until it is assigned, NAT static and dynamic 
translations cannot be configured. Therefore, to accommodate this type of configuration, 
Cisco uses Easy IP. Essentially, this is what happens: 


Step 1. A remote router makes a PPP connection to the ISP or a central site router. 
Easy IP uses PPP/IPCP to obtain an address from a DHCP server residing at the 
central site or ISP. 


Step 2. Easy IP receives the new "dynamic" address and assigns it to WAN interface. 


Step 3. Easy IP then uses port address translation (PAT) to perform a many-to-one 


address/port association, using multiple inside local addresses and the new global 
"dynamic" address. 


NOTE 


To configure Easy IP, you must have Cisco |OS Software Release 11.3 or later. 


To configure Easy IP, you can begin by following the four-step process outlined earlier. The 
main difference occurs in Step 4 and the enabling of |PCP. Figure 15-4 illustrates a typical 

home user or small office with an ISDN connection to an ISP. The home user does not have 
any registered IP address space and obtains an address when dialing up the ISP. This user 


also has multiple workstations that must access the Internet, providing an ideal candidate for 
Easy IP. 


Figure 15-4. Easy |P Example 
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The first step is to define inside and outside networks. Here, the inside network is the 
Ethernet, while the BRI or Dialer 10 interface is the outside network. Use the same NAT 


commands, ip nat inside and ip nat outside, to define these networks on the appropriate 
interfaces. 
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The next step is to ensure that routing exists between the router and the Internet. Because 
only one exit point exists, use a default static route pointing to the dialer interface. Be sure to 
include the ip classless command when using a default route. 


The third step involves defining what networks are to be translated and how they are 
translated. Here, you will point your translation to the Dialer 10 interface because the IP 
address is unknown. Use the overload command, which tells the router to use PAT. Doing so 
enables many connections to the Internet through one IP address. The command will look 
like the following: 


ip nat inside source list 10 interface Dialerl0 overload 


Because you don't have an address pool to define static translations, Step 4 is a good place 
to configure IPCP. To configure |PCP, you must have PPP as your Layer 2 encapsulation, and 
you must have Cisco |OS Software Release 11.3 or greater. The command to enable | PCP is 
ip address negotiated under the serial or dialer interface. Example 15-6 illustrates the 


dialer configuration and IPCP needed on the easyip_router. 


Example 15-6 | PCP and Dialer Configuration for Easy IP 


interface BRIO 

no ip address 

no ip directed-broadcast 
encapsulation ppp 

dialer pool-member 10 

isdn switch-type basic-—ni 

isdn spidl 71538154750101 3815475 
isdn spid2 71538154760101 3815476 


ppp multilink 
! 


interface Dialer10 


*“~ pcp configuration 


no ip directed-broadcast 


no ip mroute-cache 

dialer remote-name isp_router 
dialer idle-timeout 300 

dialer string 4262200 

dialer hold-queue 80 

dialer load-threshold 10 either 
dialer pool 10 

dialer-group 10 

compress stac 

no cdp enable 

ppp authentication pap 

Ppp pap sent-username ksolie password 7 1304474B5B5D577E 
ppp multilink 


Notice that most ISPs also use PAP for authentication. This also might be a requirement for 
your configuration to the ISP. For more information on the dialer configurations or ISDN 
setup, see Chapter 7, "WAN Protocols and Technologies: Integrated Services Digital Network 
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(ISDN)." 


Example 15-7 lists the entire configuration needed for Easy IP. 


Example 15-7 Easy I P Configuration 


hostname easyip_router 
! 
ip subnet-—zero 
! 
isdn switch-type basic—ni 
! 
interface Ethernet0O 
ip address 172.16.1.254 255.255.255.0 
no ip directed-broadcast 


! 

interface BRIO 

no ip address 

no ip directed-broadcast 
encapsulation ppp 

dialer pool-member 10 

isdn switch-type basic—ni 

isdn spidl 71538154750101 3815475 
isdn spid2 71538154760101 3815476 
ppp multilink 

! 
interface Dialer10 


no ip directed-broadcast 


no ip mroute-cache 

dialer remote-name isp_router 
dialer idle-timeout 300 

dialer string 4262200 

dialer hold-queue 80 

dialer load-threshold 10 either 
dialer pool 10 

dialer-group 10 

no cdp enable 

ppp authentication pap 


Ppp pap sent-username ksolie password 7 1304474B5B5D577E 


ppp multilink 


access-list 110 permit ip any any 
dialer-list 10 protocol ip list 110 
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The "Big show" and "Big D" for NAT 


The "big show" commands for NAT are show ip nat translations for detailed NAT table 
listings and show ip nat statistics for a broader view of the translations occurring on the 
router. 


The show ip nat translations command displays all NAT translations on the router. It lists 
the protocol, along with the inside and outside global and local translations. Example 15-8 
demonstrates the use of the command from the previous Easy IP model. This example shows 
two workstations, 172.16.1.10 and 172.16.1.11, accessing two hosts on the Internet, using 
the same inside local address, 206.191.194.42. The address 206.191.194.42 was the address 
assigned dynamically from the ISP when you connected. 


Example 15-8 show ip nat translations Command Output 


easyip_router#show ip nat translations 

Pro Inside global Inside local Outside local Outside global 
tep 206.191.194.423 1169 7 2el6.1,.LOosileo 98. 1S32Z219225280. 198 .1332219..25930 
tep- 206,191,194 4221068 172216: 0.108116s 98 .13s.219525380. 199.133. 219.25230 


tcp 206.191.194.42:1045 172.16. 
udp 206.191.1794 42271057 172.16. 
easyip_router# 


sLIsO4S 6ac2ol8s 23380 63.291.85 23330 
sLiTLOS? 2OGs1O1 19301253 2066797 . 193.1353 


tep: 2066 191.194.4209, 272.16. 1Ostr DSS. 133. 20925280 9S .133.219. 25360 
tep 206,191.194,42221070 L7IZ.1O.Led0tL 170. 198.033.219;.25380 1962.133.219.25780 
tep 206¢191.194.4251175 L216. DsLOsiiis 298.33. 219.25280 198.133 .219.25780 
tep 206,191,194 42211072 V72.16.1.10s1072 198.133.219.25¢80 198.133. 219.25780 
tep 2066191. 194.4250 067 D72.1Os1.LOrI ley 2S. 133.219.25280 098.133.2219 .25 380 
udp 206.191.194.423: 1050 L72.16.12 2131050 206.190.193.1353 206,191. 193.1353 
udp 206.191.194.427 1048 172.16.1,0131048 206. 191.193 1353 206.191, 193.1953 
udp: 206.191.1194. 4271049 272.16.1.2051049. 206.191.193..10353 206. 19d 6 93.53 
udp 2062.191.194.42:1046 172.16. 151081046 206.191.1093 1253 206.191 ,193..1453 
udp 206.191.194.42:1044 172.16.1.11:1044 206.191.193.1:53 206 1 Oil. OS. ISS 

1 
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NOTE 


The easiest way to test NAT in any of the three configurations is to test for IP 
connectivity from the inside network to a host on the outside network. This can 
be accomplished with a source ping, assuming that you're translating |CMP 
traffic. 


The show ip nat statistics command summarizes NAT's operation on the router. It lists the 
active translations and tells whether they are static, dynamic, or extended. This command 
also shows the NAT inside and outside interfaces. Example 15-9 lists the output of this 


command on the easy_ip router. 


Example 15-9 show ip nat statistics Command 


easyip_router#show ip nat statistics 
Total active translations: 12 (0 static, 12 dynamic; 12 extended) 
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Outside interfaces: 
BRI0O:1, BRI0O:2, Dialerl0, Virtual-Access1 
Inside interfaces: 
Ethernet0 
Hits: 2304 Misses: 190 
Expired translations: 134 
Dynamic mappings: 
—-— Inside Source 
access-list 10 interface Dialerl0O refcount 12 


In this example, the translations are all dynamic and extended. In the code, Hits refers to 
the number of times that Cisco |OS Software does a translation table lookup and finds an 
entry, whereas Misses refers to the number of times that it fails to find an existing 
translation and must create a new one. Expired translations lists a cumulative count of 
translations that have expired since the router was booted. 


The show ip nat translations verbose command displays more detailed information about 
each translation than the show ip nat translations command, including the time it was 
created, the time it was in use, and expiration time. Any flags, such as extended port 
translation, are also noted. Example 15-10 lists the output of the command from the previous 
Easy IP example. 


Example 15-10 show ip nat translation verbose Command Output 


easyip_router#show ip nat translations verbose 
Pro Inside global Inside local Outside local Outside global 


create 00:00:23, use 00:00:22, left 23:59:37, flags:extended 


create 00:00:23, use 00:00:23, left 23:59:36, flags:extended 
tcp 206.191.194.422 71065 172.16.) .L1s1065° 129.171.2025, 241730 128 .11.25.241 580 
create 00:00:23, use 00:00:23, left 23:59:36, flags:extended 
easyip_router# 


A limited number of debugs are available for NAT, and they all stem from the debug ip nat 
command. The syntax is as follows: 


debug ip nat [detailed] 


The debug ip nat command displays each individual port and address pair association of all 
active translations. The detailed variation of this command adds additional information with 
an interface perspective. It also displays port negotiation messages. A heavy warning is 
warranted to anyone using this command on a production router: The output from a single 
workstation can be high. Notice in Example 15-11 how many messages are generated per 
millisecond on a single workstation. Use this command only to track down specific NAT 
problems. 


Example 15-11 debug ip nat detailed Output from the easy_ ip Router 


easyip_router#debug ip nat detailed 

IP NAT detailed debugging is on 

OOPZ4s07s NATS as udp. (172.106.1100, 137) => (206.791.193.1, 53) [25601] 
00:24:07: NAT: ipnat_allocate_port: wanted 137 got 137 
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O10": 
OOS 
00: 
00: 
OO: 
O08 
OO: 
OO: 
00: 
O00: 


24: 
24% 
24: 
24: 
24: 
2512 NAT*® s=172.16.1.10-5206 .1791.194,.42, d=206.191..193.1 [25857 


24 


24: 
2:51: NAT: s=206.191.193.1, d=206.191.194.42->172.16.1.10 [22909 


24 


24: 
24: 


O7: NAT: s=172.16.1.10->206.191.194.42, d=206.191.193.1 [25601] 

O7: NAT: of udp (206.191.193.111, 53) =—> (206.191.194.42, 137) [44225] 
O7: NAT: s=206.191.193.1, d=206.191.194.42->172.16.1.10 [44225] 

Sls NATs as udp (172.16.1.10; 1046) => (206.191.193.1, 53) [25857] 
51: NAT: ipnat_allocate_port: wanted 1046 got 1046 


] 
bl: NAT? of udp (206.191.193.1, 53) —> (206.191.194.42, 1046) [22909] 
] 


Sle NAT? as wudp (172.16.1,10, 1047): —> (206.191,093.1, 53) [26113] 
51: NAT: ipnat_allocate_port: wanted 1047 got 1047 


CAUTION 


Use the debug ip nat commands with extreme caution. A single workstation 
can generate several entries per millisecond. Use the command with the 
logging buffered global configuration command. 
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Clearing and Changing NAT Translations 


NAT TCP translations will time out after a default of 24 hours. You can change the timeout 
values on a per-protocol basis with the following commands: 


e ip nat translation timeout seconds— Specifies the timeout value that applies to 
dynamic translation, except for ones with overload translations. The default is 86,400 
seconds, or 24 hours. 


e ip nat translation udp-timeout seconds— Specifies the timeout value of UDP 
translations. The default is 300 seconds, or 5 minutes. 


e ip nat translation dns-timeout seconds— Specifies the timeout value for DNS. The 
default is 60 seconds. 


e ip nat translation tcp-timeout seconds— Specifies the TCP timeout values. The default 
is 86,400 seconds or 24 hours. 


e ip nat translation finrst-timeout seconds— Specifies the timeout for NAT TCP flows 
after a FIN or RST bit is set in the TCP header. The default is 60 seconds. 


e ip nat translation icmp-timeout seconds— Specifies the timeout for NAT ICMP packets. 
The default is 60 seconds. 


e ip nat translation port-timeout [tcp | udp] port_number seconds— Specifies the 
timeout value for specific TCP or UDP port numbers. 


e ip nat translation syn-timeout— Specifies the timeout value for NAT TCP flows 
after the SYN bit is set, and gives no further data. 


To clear NAT translations or statistics, use the following commands: 


e clear ip nat translations [*| inside inside_address | outside outside address | tcp 
port_number | udp port_number] 
e clear ip nat statistics 
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NAT Limitations and Uses 


NAT provides a great alternative to readdressing your network to provide access to the 
Internet and other IP services. NAT also provides inherent security for the inside network by 
preventing outside network hosts from initiating sessions. However, NAT does have its 
limitations. Many protocols, such as SNMP and BOOTP, embed an IP address in the data 
stream. Some applications ignore the source address of the IP header and, in turn, use the 
embedded address in the data stream for routing back to the host in which the message was 
received. In these instances, NAT will fail. NAT recognizes some of these traffic types, and 
special sets of instructions are used to handle that type of traffic, such as FTP. Table 15-3 


lists those traffic types that are supported and not supported by NAT. 


Table 15-3. Traffic Type Support for NAT 


Traffic Types/ Applications Traffic Types/ Applications Not 
Supported by NAT Supported by NAT 
Any TCP/UDP traffic that does not 


carry source or destination IP address 


in the application data stream In Cisco 10S Software Release 12.0.(1)T, the 
following are now supported: 


IP multicast. 


Data packet source address translation 
PIM, Auto-RP, PIM V2, and BSR 
mstat, mrinfo, and mtrace 


SDR advertisement or app. payload 


HTTP Routing table updates. 
TFIP DNS zone transfers. 
TELNET BOOTP. 


Archie Talk, ntalk. 
Finger ISNMP. 
NTP [Netshow. 
INFS | 

Rlogin, RSH, RCP | 
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The following carry IP addresses in the 
application data stream and are supported by 
NAT: 


ICMP. 


FTP. (See the following section for 
nonstandard port operation.) 


Net BIOS over TCP/IP (Datagram and name 
services only; session service support will be 
supported in a future |OS.) 


Progressive Networks' RealAudio, RTSP is not 
supported. 


White Pines' CuSeeMe. 

Xing Technologies' SteamWorks. 

DNS "A" and "PTR" queries. 
H.323-10S 12.0(1)/12.0(1)T and later. 


NetMeeting 2.1, 2.11, 3.01—IOS 12.0 
(1)/12.0(1)T and later. 


NetMeeting Directory (ILS Servers)—12.1(5) 
le 


VDOLive—1IOS 11.3(4)/11.3(4)T and later. 


Vxtreme—lOS 11.3(4)/11.3(4)T and later. 


NOTE 


NAT pools and translations are subject to the Subnet O rule. Translations will fail 
if the NAT pool is on IP Subnet 0. Cisco 1|OS Software Release 12.0 and later 
have the ip subnet zero command enabled by default. If you want to use 
Subnet O for your NAT pool on devices running Cisco |OS Software with releases 
earlier than 12.0, you will need to use the ip subnet zero command. 
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NAT and Nonstandard FTP Port Numbers 


When using FTP, the arguments to the ftp port command include an |P address embedded in 
the data stream. To accommodate this, Cisco routers recognize port 21 and take the 
appropriate steps in replacing the data with the new translated address and recomputing the 
necessary checksums. A problem happens when FTP is using nonstandard port numbers. NAT 
cannot recognize the data stream as being an FTP request, so it passes the packet along 
without the necessary modifications. Naturally, the request will fail when it reaches the host 
because the address in the payload differs from the address in the IP header. 


In Cisco |OS Software Release 11.3(3) and Cisco |OS Software Release 11.2.(13), Cisco 
introduced the capability to use nonstandard TCP port numbers for FTP. The command ip nat 
service list [1-100] ftp tcp port xxxx calls an access list of the networks to be translated 
and then looks for FTP packets operating on port xxxx. If the router finds a match, it makes 
the necessary changes to that packet for FTP to operate. 
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Lab 31: Configuring Dynamic NAT and Using Non-Standard FTP Port 
Numbers—Part | 


Practical Scenario 


As internetworks grow together and access to the Internet increases, so will the need to use NAT. 
To add security to a network, NAT can also be deployed. By not propagating a subnet with a 
routing protocol, you can protect an internal network from any outside session initiation. 


Lab Exercise 


The Durand school district decided to merge two smaller high schools to form one large district. 
The JP Memorial School will be getting a T1 HDLC link to the Durand High School. The dhs_ router 
has registered CIDR blocks of 200.100.1.16/29 and 200.100.1.32/29. The jpms router is using an 
unregistered IP address range of 9.3.3.0/24. The jpms_ router requires access to the Internet, 
while restricting FTP and ping access to the server 200.100.1.18. Use the following parameters as 
your design guidelines: 


e Configure the network so that the workstations on the subnet 9.3.3.0/24 can access to the 
Internet, while restricting access to the 200.100.1.16/29 subnet. 

e Control access so that NAT works to the Internet, but only NAT ICMP and FTP when traffic 
is destined toward the host 200.100.1.18. 

e Use the CIDR block of 200.100.1.32/29 for your address pool. 

e Optional: Configure FTP to work on port 2021 instead of port 21. 


Lab Objectives 


e Configure the network as depicted in Figure 15-5. Use a loopback address to simulate the 


Internet. For lab purposes, you will use the address of 198.133.219.25/24 on a loopback 
interface to simulate the Internet. 


Figure 15-5. DHS School District—Dynamic NAT 
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e Configure NAT so that the 9.3.3.0/24 subnet can reach the address 198.133.219.25. 
Restrict NAT access to only FTP, and ping to the host of 200.100.1.18. You should not be 
able to ping 200.100.1.17 from the 9.3.3.0/24 subnet. 

e Do not make a route to the jpms_router's Ethernet from the dhs_router. Do not propagate 
the 9.3.3.0/24 subnet with a routing protocol. 


Equipment Needed 
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Two Cisco routers. The routers should be connected through V.35 back-to-back cables or 
in a similar manner. Cisco |OS Software Release 11.2 or later and releases 11.2(13) or 
11.3(3) and later for the optional portion of the lab. 

Two LAN segments, provided through hubs or switches. 

Two IP workstations, one to serve as an FTP server and one to serve as the client 
workstation. You can download FTP server and client software from DOWNLOAD.CNET. 


COM. 


Physical Layout and Prestaging 


Connect the hubs and serial cables to the routers, as shown in Figure 15-5. 

Connect the two Ethernet hubs to the routers to form two LAN segments, as shown in 
Figure 15-5. 

Connect and configure two IP-based workstations, as shown in Figure 15-5. Make the 
workstation 200.100.1.18 the FTP server, and make 9.3.3.10 the FTP client. Copy a test 
file into the public directory of the FTP server for testing. 

Optional: Configure FTP to operate on port 2021 instead of port 21. Do this by changing 
the server software to run on port 2021. You also need to make sure that the client is set 
to connect on 2021. 
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Lab 31: Configuring Dynamic NAT and Using Non-Standard FTP 
Port Numbers—Part Il 


Lab Walkthrough 


After completing the physical installation of the serial link and the two Ethernet segments, 
establish IP connectivity between the appropriate subnets. 


Beginning with the dhs_router, configure the IP addresses of Ethernet and serial interfaces. 
The Serial 0 port is the DCE side of the link, so this side will have the clockrate command. 
You are not allowed to "see" the 9.3.3.0/24 subnet from this router. Instead, you will have 
assigned the router a CIDR block 200.100.1.32/29 for NAT. This is the network that you need 
a route to. Therefore, you will make a static route to it on the dhs_ router. 


For the lab purpose, you may or may not have a connection to the Internet. If you don't have 
a connection to the Internet, simulate an IP host by adding a loopback interface with the 
address 198.133.219.25. You should be able to ping this address from the 9.3.3.0/24 subnet 
when NAT is working properly. Example 15-12 lists the configuration for the dhs_ router. 


Example 15-12 dhs_ router Configuration 


hostname dhs_router 
! 
<<<text omitted>>> 
! 
interface Loopback20 
ip address 198.133.219.25 255.255.255.0 
! 
interface Ethernet0O 
ip address 200.100.1.17 255.255.255.248 
! 
interface Serial0O 
ip address 192.168.11.5 255.255.255.252 
no fair-—queue 
clockrate 2000000 
! 
<<<text omitted>>> 
! 
no ip classless 
ip route 200.100.1.32 255.255.255.248 192.168.11.6 


The configuration for the jpms_router will be a little more involved. Begin by assigning the 
appropriate IP addresses to the Ethernet and serial interfaces. You need to configure a 
default route pointing to 192.168.11.5. Don't forget to include the ip classless command 
when using a default route: 


ip classless 
ip route 0.0.0.0 0.0.0.0 192.168.11.5 


At this point, you should be able to ping the "Internet" address of 198.133.219.25 from the 
router. If you issue a source ping from the router's Ethernet 0 interface or from the 
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workstation 9.3.3.10, you should not be able to reach the "Internet" or the 200.100.1.16/29 
subnet. 


You can now begin to configure NAT on the jpms_ router. First, define the inside and outside 
networks. Figure 15-6 illustrates the inside and outside networks from the jpms_router's 


perspective. After defining the inside and outside networks, configure them by using the ip 
nat outside command on the Serial interface and ip nat inside on the Ethernet interface. 


Figure 15-6. DHS School District Inside and Outside Networks 
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The next step in configuring NAT is to ensure that IP routing exists between the pool and the 
dhs_router. You have the IP subnet of 200.100.1.32/29 assigned to you from DHS. You must 
tell the jpms_router that this subnet exists on it. To accomplish this, use a loopback interface 
and assign the IP address of 200.100.1.33 to it. Note that this is the only subnet that you 
have a Static router to on the dhs_ router. 


The third step in configuring NAT is to define the range of addresses and protocols that get 
translated. In this case, you want to translate FTP and ICMP to only one host, 200.100.1.18, 
when going to the 200.100.1.16/29 subnet. You also want to translate any addresses 
destined toward the Internet. To achieve this, use a route map on the ip nat inside source 
command. The route map can call an extended access list, where you can make decisions on 
specific traffic types. You also must use the pool keyword on this command. Example 15-13 
demonstrates the command, along with the route map and access list needed on the 
jpms_router. 


Example 15-13 Configuring the Addresses and Protocols to Be 
Translated 


jpms_router (config) #ip nat inside source route-map trans_nat pool legalpool 
jpms_router (config) #route-map trans_nat permit 10 
jpms_router(config-route-map) # match ip address 101 
jpms_router (config-route-map) #exit 
jpms_router (config) # access-list 101 permit icmp 9.3.3.0 0.0.0.255 
host 200.100.1.18 echo 
jpms_router (config) # access-list 101 permit icmp 9.3.3.0 0.0.0.255 
host 200.100.1.18 echo-reply 
jpms_router (config) # access-list 101 permit tcp 9.3.3.0 0.0.0.255 
host 200.100.1.18 eq ftp 


jpms_router (config) # access-list 101 deny ip 9.3.3.0 0.0.0.255 4019 


200.100.1.16 0.0.0.7 


jpms_router (config) #access—list 101 permit ip 9.3.3.0 0.0.0.255 any 


The last step is to define and configure your NAT pool. Because you do not want to translate 
the host address of the loopback interface, the pool will have a starting address of 
200.100.1.34 and an ending address of 200.100.1.38, ignoring the broadcast address of 
200.100.1.39. Using the following command, you can configure the NAT pool, called legalpool: 


jpems_router(config)# ip nat pool legalpool 200.100.1.34 200.100.1.38 
netmask 255.255.255.248 


Example 15-14 provides the entire configuration for the jpms_router. 


Example 15-14 Configuration of the jpms_ router 


hostname jpms_router 
! 
<<<text omitted>>> 
! 
interface Loopback20 
ip address 200.100.1.33 255.255.255.248 
no ip directed-broadcast 
! 
interface Ethernet0 
ip address 9.3.3.1 255.255.255.0 
no ip directed-broadcast 
ip nat inside 
! 
interface Serial0 
ip address 192.168.11.6 255.255.255.252 
no ip directed-broadcast 
ip nat outside 
no ip mroute-—cache 


<<<text omitted>>> 

! 

ip nat pool legalpool 200.100.1.34 200.100.1.38 netmask 255.255.255.248 
ip nat inside source route-map trans_nat pool legalpool 

ip classless 

ip route 0.0.0.0 0.0.0.0 192.168.11.5 


access-list 101 permit icmp 255 host 200.100.1.18 echo 
access-list 101 permit icmp 255 host 200.100.1.18 echo-reply 
access-list 101 permit tcp 9.3.3.0 0.0.0.255 host 200.100.1.18 eq ftp 


9.3.3.0 0.0.0. 
9.3.3.0 0.0.0. 


access-list 101 deny ip 9.3.3.0 0.0.0.255 200.100.1.16 0.0.0.7 
access-list 101 permit ip 9.3.3.0 0.0.0.255 any 
route-map trans_nat permit 10 


match ip address 101 


jJpms_router# 


You can now test the configuration with the workstation 9.3.3.10 on the jpms_router. To 
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properly test this particular NAT configuration, you need two IP workstations. The one on 
dhs_router will be running FTP server software, and the workstation on the jpms_ router will 
be configured as the FTP client. ping the FTP server from the client workstation. You should 
be able to ping the server but not the Ethernet port of the dhs_router. You should also be 
able to ping the address 198.133.219.25. Test the FTP portion of the configuration by 
initiating an FTP session from the client to the server. 


Be sure that you can transfer a file across the network. If you are having problems, ensure 
that the dhs_router can reach the IP pool on the jpms_router. We are not running any 
routing protocols, so the routers, servers, and stations that you are using for this test need to 
have the appropriate default or static routing to gain reachability. Verify that your route map 
calls the correct access list. Use the show access-list command to ensure that your access 
list is taking hits and is properly configured. In addition, be sure that your NAT pool host 
addresses are on the same subnet as your loopback interface. This "anchors" the subnet to 
that router and eventually to the NAT pool. Example 15-15 lists the show commands 


illustrating NAT translations while testing the network. 


Example 15-15 Configuring NAT Inside and Out 


jpms_router#show ip nat trans 


Pro Inside global Inside local Outside local Outside global 

wenp ZO0.L00cI.332512° 9.3.3 2.108512 Z00 2100215182512 2002100. 12183512 
tep 200:10021.3321076 9.3.3:1051076 200. 100 2d. TBe2i 200.100). 1. 18227 
tep 200 c100.1.3321077 9.323.105 1077 200:.100..1.16:220 200...100.. 1.18220 
Eep 200<.100.1. 3351072 9.3.3.1051072 2002100 21.2183 24 200.1002. 18s 21 


jpms_router# 

jpms_router#show ip nat stat 

Total active translations: 1 (0 static, 1 dynamic; 1 extended) 

Outside interfaces: 

Serial0O 
Inside interfaces: 
Ethernet0 

Hits: 3727 Misses: 87 

Expired translations: 89 

Dynamic mappings: 

—- Inside Source 

route-map trans_nat pool legalpool refcount 1 

pool legalpool: netmask 255.255.255.248 

start 200.100.1.33 end 200.100.1.38 
type generic, total addresses 6, allocated 1 (16%), misses 0 

jpms_router# 

jpms_router# show access-lists 

Extended IP access list 101 
permit icmp 9.3.3.0 0.0.0.255 host 200.100.1.18 echo (1 match) 
permit icmp 9.3.3.0 0.0.0.255 host 200.100.1.18 echo-reply 
permit tcp 9.3.3.0 0.0.0.255 host 200.100.1.18 eq ftp (2 matches) 
deny ip 9.3. 0.0.0.255 200.100.1.16 0.0.0.7 (4 matches) 
permit ip 9. 0 0.0.0.255 any (1 match) 

jpms_router# 


330 
eyo 


The optional portion of this lab illustrates some new features of NAT that Cisco has 
introduced to help deal with some well-known applications that transport an IP address in the 
data stream. FTP is one such application. Because this application is so well Known, when a 
Cisco router identifies port number 21 in a NAT translation, it modifies the data portion of the 
packet and also the IP header and checksums. This solution works great as long as FTP 
operates on port 21. When FTP connections occur on a port other then 21, NAT cannot 
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properly handle the packet. Example 15-16 shows the debug ip nat detailed output of a 
packet failing to be translated properly. 


Example 15-16 debug ip nat detailed List of an FTP Port Failure 


jpms_router#debug ip nat detailed 
IP NAT detailed debugging is on 

jpms_router# 

11:36:27: NAT: 
11:36:27: NAT: 
11:36:27: NAT: 
1is36¢3Le NAT: 
Dbsseot 31 NAT? 
NAT 


udp (9.363.205. LUS4)) => (206.191 .L9S sd, 53) [36138] 
udp: (9.353210, 2154) => (204.221.152.213, 53) [36394] 
Lemp: (192.168. 11.5; 53) —> (200.100.1633, 1154). [524] 
udp: (95323.10, 1154) => (2062191 293.1, 53) 36650) 
udp (9.3.3.10, 1154) -—> (204.221.151.213, 53) [36906] 
Lemp (192.168.1125) 53) = (200.100.1033, 1154) 


O FRO RE 


& 
hb 
Ww 
(o>) 
Ww 
hb 
oO 
Be) 
oO 


i= 
b 
W 
~] 
W 
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NAT: deleting alias for 200.100.1.33 


i? udp (9.3.3.10,. 1158). => (206.191.793.141, 
2:40:09: NAT: map match trans_nat 
11:40:09: NAT: installing alias for address 200.100.1.33 
11:40:09: NAT: alias insert failed for 200.100.1.33 


53) [40490] 


ao 
ao 


jpms_router#debug ip nat detailed 
IP NAT detailed debugging is on 
jpms_router# 


: O: ( 18; 21). => (200.100 21.33; 1745) (41225) 
113333038 NATS 13 tep (9.3.3.10,; 1145) -—> (200.100.1.18, 21) [12303] 
113332033 NATS of tep (200.100.1.18, 21) —> (200.100.1.33, 1145) [41481] 
11333303 NAT? 23 tep (9.3.3.10, 1145) <> (200.100.1.18, 21) [12559] 


Here, you are receiving inbound and outbound requests to 200.100.1.18 on port 21, 
demonstrating a successful translation. 
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To allow FTP through NAT on a port other then 21, use the ip nat service command and add 
an access list identifying the FTP hosts. In this lab, you have to make an additional 
modification to your access list to include TCP port 2021. Example 15-18 shows the 


configuration changes. 


Example 15-18 Using Nonstandard FTP Port Numbers and NAT 


jpms_router (config) #ip nat service list 1 ftp tcp port 2021 

jJpms_router(config)# access-list 1 permit 200.100.1.18 

jpms_router(config)# no access-list 101 

jpms_router(config)# access-list 101 permit icmp 9.3.3.0 0.0.0.255 
host 200.100.1.18 echo 

jpms_router(config)# access-list 101 permit icmp 9.3.3.0 0.0.0.255 
host 200.100.1.18 echo-reply 

jpms_router(config)# access-list 101 permit tcp 9.3.3.0 0.0.0.255 
host 200.100.1.18 eq 2021 

jpms_router (config) # access-list 101 deny ip 9.3.3.0 0.0.0.255 
200.100.1.16 0.0.0.7 

jpms_router (config) #access-list 101 permit ip 9.3.3.0 0.0.0.255 any 


NAT now recognizes that port 2021 to host 200.100.1.18 is an FTP data stream, and it makes 
the necessary modifications to support that protocol. Example 15-19 lists the output from the 


show debug ip nat detailed command, showing the use of FTP port 2021 successfully. 


Example 15-19 debug ip nat detailed List of FTP on Port 2021 


i eA Be as INAL's 
11:48:17: NAT: 
11:48:17: NAT: 
11348173 NAT* 
11:48:17: NAT: 
1i2463173 NAT: 


tep (9.3.3.10,. 1164) -—> (200.100.1.18, 2027) [52266] 
tep (200.100.171.138, 2021) —<> (200.100.1.33, 1164) [4645] 
tep- (95323 210,. 1164) => (2002. 100;1.108,. 2021) [s2522] 
tep (200.100.1138, 2021) => (200.L00..1.33, L164). [sisy] 
tep: (9.353.10,;. L644) => (200.100.0018, 2021) [S2778] 
tep: (200.100. 1.18, 2021). => (200.100.121.335, 1164) [5413] 


OrFOHOF 
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Lab 32: Configuring Static NAT and DLSw—Part | 


Practical Scenario 


As automation increases through the network, many users have IP addresses of applications 
defined in specific user setups. When IP addresses change, it can cause a great deal of labor 
changing individual scripts and host files on many workstations. In cases such as this, a static 
mapping of NAT addresses is desirable, to avoid using a different translation address every 
time the service is required. Static mapping also allows outside networks to make session 
initiations to the inside network. Keep in mind that this works only if the application does not 
transport the IP addresses in the data stream. 


Lab Exercise 


Harms Co., a leading consulting and guide company in northern Wisconsin, is going through 
an IP address migration. To avoid having to change all the addresses and host tables at once, 
Harms Co. will use NAT to assist in the migration. The subnet 190.10.1.0/24 previously 
resided on the Ethernet segment of the green_bay router. Many hosts (not depicted in Figure 
15-7 for this lab) have static entries to the hosts on the 190.10.1.0/24 subnet. The new 
subnet 210.168.1.0/24 will be placed on the Ethernet segment of the green_bay router. NAT 
will be required to preserve the current host tables of the workstations that reside on the 
Ethernet segment of the harms_co router. Based on this scenario, the configuration exercises 
for this lab are as follows: 


Figure 15-7. The Harms Co. Network—Static NAT with DLSw 
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e Configure the network as depicted in Figure 15-7. Configure the network with EIGRP 
as the routing protocol. Use an autonomous System ID of 7. 

e Configure green_bay so that the router does not circulate the new subnet of 
210.168.1.0/24 in EIGRP. 

e Configure static translations as follows: 


- 210.168.1.254 translates to 190.10.1.1 


- 210.168.1.250 translates to 190.10.1.2 
e Optional: Configure a DLSw peer between the harms_co router and the green_bay 
router. Use 198.100.1.10 as the local peer on harms_co, and use 210.168.1.254 as 
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the local peer on the green_bay router. 
Lab Objectives 


e Configure the network as depicted in Figure 15-7. Use EIGRP as the routing protocol, 


and do not propagate the 210.168.1.0/24 subnet in EIGRP. 
e Configure NAT static translations as follows: 


- 210.168.1.254 translates to 190.10.1.1 
- 210.168.1.250 translates to 190.10.1.2 
Equipment Needed 


e Three Cisco routers. Two routers should be connected through V.35 back-to-back 
cables or in a similar manner. The third router will connect to another router by an 
Ethernet segment. Cisco |OS Software Release 11.2 or later is also required. 

e Two LAN segments, provided through hubs or switches. 

e Two !P workstations will aid in the testing of the NAT configuration. 


Physical Layout and Prestaging 


e Connect the hubs and serial cables to the routers, as shown in Figure 15-7. 
Connect the two Ethernet hubs to the routers to form two LAN segments, as shown in 
e Connect and configure two IP-based workstations, as shown in Figure 15-7. This is 
optional, but it will aid in testing the NAT configuration. 
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Lab 32: Configuring Static NAT and DSLw—Part Il 


Lab Walkthrough 


After completing the physical installation of the serial link and the two Ethernet segments, establish IP 
connectivity between the appropriate subnets. Use EIGRP as the routing protocol on all routers. Be sure that you 
do not route the subnet 210.168.1.0/24 with EIGRP. 


Beginning with the green_bay router, define which networks will be the inside and outside networks. In this lab, 
networks 198.100.1.0/24 and 190.10.5.4/30 are outside networks, while 210.168.1.0/24 and 190.10.1.0/24 are 
inside networks. Configure the EO port with the ip nat inside command, and configure the SO port with the ip 
nat outside command. 


Next, you must ensure that IP connectivity exists between the IP subnet 190.10.1.0/24 and the rest of the 
network. Do this by creating a loopback interface and using an IP host address from the 190.10.1.0/24 subnet. 
You should be able to ping this address/subnet from the harms_co router when routing is established. Example 
15-20 lists the commands needed to accomplish the first two steps on NAT configuration. 


Example 15-20 Configuring NAT on the green_ bay Router 


green_bay (config) #int e0 
green_bay(config-if)#ip nat inside 
green_bay(config-if) #int sO 
green_bay(config-if)#ip nat outside 
green_bay (config-if) #exit 

green_bay (config) #router eigrp 7 

green_bay (config-router) #network 190.10.0.0 
green_bay (config-router) #*Z 

green_bay# 


You now can define what addresses you want to translate with NAT. On the green_bay router, you want to 
translate address 210.168.1.250 to 190.10.1.2 and 210.168.1.254 to 190.10.1.1. This can be done with the 
following global NAT command: 


ip nat inside source static 210.168.1.250 190.10.1.2 
ip nat inside source static 210.168.1.254 190.10.1.1 


At this point, the workstation 210.168.1.250 can reach the rest of the network. Hosts on the outside networks 
also can reach 210.168.1.250 and 210.168.1.254 through 190.10.1.2 and 190.10.1.1, respectively. Example 15- 


21 shows the NAT table from the green_bay router. 


Example 15-21 show ip nat translations on the green_ bay Router 


green_bay#show ip nat trans 


Pro Inside global Inside local Outside local Outside global 
tep 190.10.1.2:1084 210.168.1.250:1084 198.100.1.50321 198,100.41 ,.50221 
ees 1905012 210.168.1250 == a= 

ees 1905 05160 210.168.1.254 === == 

green_bay# 


Example 15-22 lists the chippewa_falls configuration and the green_bay configuration, respectively. 


Example 15-22 chippewa_falls and green_ bay Router Configurations 


hostname chippewa_falls 
! 
<<<text omitted>>> 
! 
interface Ethernet0O 
ip address 198.100.1.1 255.255.255.0 1026 


! 

interface Serial0 

ip address 190.10.5.5 255.255.255.252 
no fair-—queue 
clockrate 2000000 

! 

<<<text omitted>>> 

! 

router eigrp 7 
network 198.100.1.0 
network 190.10.0.0 


hostname green_bay 
! 
<<<text omitted>>> 
! 


no ip directed—-broadcast 

! 

interface Ethernet0O 

ip address 210.168.1.254 255.255.255.0 
no ip directed—-broadcast 


! 

interface Serial0 

ip address 190.10.5.6 255.255.255.252 
no ip directed—-broadcast 


no ip mroute-—cache 
no fair-—queue 

! 
<<<text omitted>>> 
! 

router eigrp 7 
network 190.10.0.0 


! 
<<<text omitted>>> 


The optional portion of this lab exploits a DLSw issue with NAT. First, you will walk through the configuration as 
specified. Configure DLSw using 210.168.1.254 as the local peer on the green_bay router, with a remote peer 
pointing toward 198.100.1.10. Example 15-23 shows the DLSw configuration. 


Example 15-23 DLSw Configuration Using 210.168.1.254 as the Local Peer on the 
green_bay Router with a Remote Peer Pointing Toward 198.100.1.10 


disw local-peer peer-id 210.168.1.254 
dlsw remote-peer 0 tcp 198.100.1.10 
disw bridge-group 1 

! 

interface Ethernet0O 

ip address 210.168.1.254 255.255.255.0 
no ip directed—-broadcast 

ip nat inside 

bridge-group 1 


Example 15-24 shows the configuration of DLSw on the harms_co router. 


Example 15-24 DLSw Configuration on the harms_co Router 


dlsw local-peer peer-id 198.100.1.10 promiscuous 
dlisw bridge-group 1 
! 
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interface Ethernet1l 

ip address 198.100.1.10 255.255.255.0 
media-type 10BaseT 

bridge-group 1 


This configuration is correct; however, DLSw will encounter an error because of NAT. By watching the peers, you 
can observe that they never connect, despite the fact that there is |P connectivity between them. RFC 1795 
specifies how TCP connections are handled with a control vector. During the capabilities exchange, a control 
vector is negotiated. DSLw uses two TCP sessions for data exchange. Cisco routers will use only one TCP session 
and will tear down the other TCP connection. When the router determines what TCP session to tear down, it 
looks for the highest IP address on the peer statement and drops that TCP connection. 


In this lab, the harms_co router believes that its IP address is 198.100.1.10 and that the remote peer address is 
190.10.1.1. Therefore, it tears down its TCP connection. On the green_bay router, it sees its IP address as 
210.168.1.254 and the remote peer address as 198.100.1.10. Therefore, it tears down its TCP connection. 
Because both sides tear down what they believe is the highest |P address, the connection is terminated. Example 


15-25 demonstrates this with the debug disw peer and debug disw core commands. 


Example 15-25 debug Showing the Teardown of TCP Sessions 


a 
ow 
8 
5 
a 
Q 
fe) 
se 


DLSw: dtp_action_c() opening write pipe for peer 190.10.1.1(2065) 
DLSw: END-TPFSM (peer 190.10.1.1(2065)): state:DISCONN->WWR_RDOP 


ers] 
NN 
NN 
PR 
oo 
NN 


02:21:02: DLSw: Async Open Callback 190.10.1.1(2065) -> 11006 

02:21:02: DLSw: START-TPFSM (peer 190.10.1.1(2065)): event:TCP-WR PIPE OPENED st 
ate :WWR_RDOP 

02:21:02: DLSw: dtp_action_i() write pipe opened for peer 190.10.1.1(2065) 


02:21:02: DLSw: START-TPFSM (peer 190.10.1.1(2065)): event:SSP-CAP MSG RCVD stat 
e:WAIT_CAP 
02:21:02: DLSw: dtp_action_j() cap msg rcvd from peer 190.10.1.1(2065) 


fo) 
i) 
No 
a 
(o) 
i) 


DLSw: Unknown CV D9 with length 3 from peer 190.10.1.1(2065) 


02:21:02: DLSw: END-TPFSM (peer 190.10.1.1(2065)): state:WAIT_CAP->WAIT_CAP 
02:21:02: DLSw: START-TPFSM (peer 190.10.1.1(2065)): event:SSP-CAP MSG RCVD stat 
e:WAIT_CAP 


02:21:02: DLSw: dtp_action_j() cap msg rcevd from peer 190.10.1.1(2065) 


02:21:02: DLSw: END-TPFSM (peer 190.10.1.1(2065)): state:WAIT_CAP->PCONN_WT 
02:21:02: DLSw: Processing delayed event:TCP-PEER CONNECTED - prev state:PCONN_W 
E 

02:21:02: DLSw: START-TPFSM (peer 190.10.1.1(2065)): event:TCP-PEER CONNECTED st 
ate:PCONN_WT 

02:21:02: DLSw: dtp_action_m() peer connected for peer 190.10.1.1(2065) 

02:21:02: DLSw: END-TPFSM (peer 190.10.1.1(2065)): state:PCONN_WT->CONNECT 
02:21:02: DLSw: dlsw_tcpd_fini() for peer 190.10.1.1(2065) 

02:21:02: DLSw: START-TPFSM (peer 190.10.1.1(2065)): event:ADMIN-CLOSE CONNECTIO 


N state:CONNECT 
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02:21:03: DLSw: freeing 190.10.1.1 


The workaround for this problem is to ensure that both sides of the DLSw connection view the other peers in a 
consistent numerical order. Instead of translating to 190.10.1.0/24, you need to translate to an IP address 
higher than 198.100.1.10, such as 199.100.1.0/24. This way the local peer on the green_bay router will always 
be the higher of the two peers, even through NAT translations. A quicker workaround is to add a loopback 
interface to the harms_co router that is lower then 190.10.1.1, and making this the new local peer. For example, 
you can add a loopback interface with the IP address of 100.100.1.1 and make this the new local peer, as done 


in Example 15-26. 


Example 15-26 Configuring a Loopback Interface as the Local Peer 


dlsw local-peer peer-id 100.100.1.1 promiscuous 
disw bridge-group 1 
! 


interface Loopback20 
ip address 100.100.1.1 255.255.255.0 


Now, you can add a new remote peer to the green_bay router pointing at 100.100.1.1, and the DLSw peer will 
connect through a NAT translation. 
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Chapter 16. Using Hot Standby Routing Protocol 
(HSRP) 


You might think that Cisco should have named HSRP (the Hot Standby Routing Protocol) as 
HSDG instead, for Hot Standby Default Gateway. This is exactly what HSRP provides to the 
hosts residing on local LANs. It seems that the name HSRP can imply a lot of things about 
"backup" that it actually doesn't provide. Many times, it has been necessary to explain 
exactly what HSRP can do for a customer's network besides give it a great name. 


HSRP provides a consistent and reachable network layer address for IP and, in limited forms, 
IPX. By providing a constant address, even upon failure, a form of redundancy can occur. The 
most common deployment of HSRP is in LAN environments, where two routers "Share" a 
common host address between them. This common address, called the hot standby address, 
is used as the default gateway for all the local hosts on that LAN segment. One router acts as 
the primary router and actually receives traffic destined for the hot standby address. The 
secondary router ignores this traffic until a configured set of circumstances is reached that 
affects the router's HSRP priority or standby priority. When the secondary router's priority 
exceeds the primary, it starts servicing requests for the hot standby address becoming the 
primary router. From the workstation's point of view, it has a single default gateway, pointing 
to the hot standby address. Figure 16-1 illustrates a common HSRP deployment. 


Figure 16-1. HSRP in a Typical Network 
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In Figure 16-1, all the TCP/IP clients have a default gateway set to 172.16.1.1. The default 
gateway tells the IP client to forward any traffic not found on a local subnet to a specific IP 
address. The 172.16.1.1 address then is used as the HSRP virtual address. In this example, 
the router caladan is configured to track the serial interface to arakas. This means that if the 
serial interface enters a down state, it decrements the router's priority by 10 or by another 
configured value. While the serial interface is up, caladan receives and forwards IP packets 
from the workstations. If the serial interface on caladan drops, giedi_ prime becomes the 
primary HSRP router. It immediately starts to service IP packets from the workstations, 
preserving all active sessions. The loss of the caladan router is completely transparent to the 
workstations on the LAN segment. 


HSRP is most effective in scenarios that involve hosts defaulting traffic to a single network 
address, such as in Figure 16-1. 
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HSRP Overview and Configuration 


HSRP uses the exchange of multicast messages to communicate a configured priority with other 
routers in the same standby group. The priority defines which router will be the primary and which 
router(s) will be secondary in the group. The default priority is 100; the router with the highest 
priority will be the primary for the group. If the priorities are the same, the first router up becomes 
the primary. Any prioritization is then based on the IP address. If a new router (at the same priority) 
joins, it doesn't bump the current primary router, even if its IP address is higher; however, it can 
bump the current standby router. 


If priorities are different, a new router joining with a higher priority becomes active, even if 
preemption is not configured; however, if the router is already up and its priority changes (because of 
tracking or reconfiguration), it won't bump the primary without preemption configured. 


HSRP uses three types of multicast messages to exchange standby group information: 


e Hello— The hello message contains the sending router's priority and state information. Hellos 
are exchanged every three seconds. If a router fails to send a hello in a specified amount of 
time, the receiving router, if priority dictates, becomes the primary router for the group. 


e Coup— When a secondary router becomes the primary router, it sends a coup message to the 
routers in the group. 


e Resign— When the primary router is about to shut down, or when it has received a hello 
message with a higher priority than its own, it forfeits the primary position with a resign 
message. 


To configure HSRP, use the following guidelines: 


Step 1. Pick a virtual address to use for the HSRP address. This address must be in the same 
address space that is assigned to the LAN interface where you want to run HSRP. This is also 
referred to as the standby IP address. Each router in the standby group must define the 
virtual IP address using the standby group_number ip a.b.c.d command. 


The standby group number is a unique number that identifies 1 to 255 standby groups on 
Ethernet and FDDI, and 0 to 2 different groups on Token Ring. If you do not specify a group, 
standby group 0 is used. 


If you are configuring HSRP on VLAN trunks, each VLAN or Ethernet subinterface must be ina 
different standby group. 


Step 2. Decide which router is to be the primary router. Configure a priority of at least 101 on 
this router. Also add the preempt command to make this router eligible for the primary 
router election. Step 2 can be accomplished with the standby group_number preempt and 
standby group_number priority 1-255 commands: 


- The preempt command enables the router to become the primary if it has the 
highest priority in the group. 


- The priority command assigns a priority to the router. The default priority is 100, 

and the router with the highest priority becomes the primary router, or active router. 
Step 3. Configure tracking, authentication, and timers on the primary router using the 
following commands: 


- standby group_number track interface_name [cost] 
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- When HSRP tracks an interface, it tells the HSRP process to decrement 10 from the 
priority if the interface goes down. This command can force the HSRP group to switch 
its primary and secondary routers based on whether an interface is active. The default 
cost is 10 and can be modified. 


- standby group_number authentication character_string 


This command establishes authentication messages to be included in the HSRP 
multicast. This ensures that only authorized routers can become part of the HSRP 
group. The string must match all routers in the HSRP group. 


- standby group_number timers hello_interval_ seconds holddown_timer_seconds 


The timers argument sets the interval between hello messages and the hold-down 
timer. The hold-down timer specifies how long the router waits before it declares the 
active router to be down. The defaults for these timers are 3 and 10 seconds, 
respectively. These timers must match among all routers in the group. 


- standby group_number mac-address H.H.H 


This command allows for the static entry of a MAC address. This can be useful for 
management or in filtering the HSRP addresses from downstream devices. 


Step 4. Configure the other routers in the standby group as secondary routers by using a 
priority of 99 or less. 


Step 5. Configure preempt, tracking, authentication, and timers on the secondary routers. 
NOTE 


HSRP requires a routing protocol that converges rapidly, such as EIGRP or OSPF, to 
transport packets without interruption. HSRP is designed to reroute packets upon router 
or link failure without any retransmissions or drops occurring. For this to happen, the 
router must be capable of converging quickly during a failure. 


Configuring HSRP Between Routers 


Using Figure 16-1 as an example, you will configure HSRP between the routers caladan and giedi 
prime. In this scenario, multiple IP clients reside on the Ethernet segment of 172.16.1.0/24. All the 
TCP/IP clients need access to arakasarakas for access to the Internet; caladan and giedi prime have 
access to arakas through the Frame Relay network. To exchange routing information, all routers are 
running EIGRP as the routing process. 


HSRP will provide the IP clients with uninterrupted access to arakas. To accomplish this, caladan is 
selected as the primary router, and giedi prime is the secondary router. You will use 172.16.1.1 as 
the virtual |P address between the two routers. Because the ultimate destination of the clients is 
arakas, you should track on the serial interfaces. By tracking on the serial interface, you can force 
giedi prime to become the primary if the link to arakas fails. 


NOTE 


When tracking is used, two potential situations can cause giedi prime to become the 
primary router. One is a loss of the connection to caladan, such as physical loss to the 
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Ethernet port on caladan. The second situation involves the loss of physical connectivity 
between arakas and caladan, causing the serial interface on caladan to drop. 


First, you will configure caladan. To do so, you need to add a standby group to the EO interface. You 
already know that caladan is going to be the primary, so you will need a priority greater than 100; for 
this example, use 105. You also want to track on the serial interface. The default tracking cost is 10, 
so if the caladan router looses its serial link, it will have an HSRP cost of 95. Make note of this value 
because you need to configure the priority of giedi prime to be greater then 95 but less then 105. 
Example 16-1 demonstrates the configuration of caladan. 


Example 16-1 Configuring HSRP on the Primary Router 


caladan (config) #interface ethernet 0 
caladan(config-if) #standby 1 ip 172.16.1.1 
caladan(config-if) #standby 1 priority 105 
caladan(config-if) #standby 1 preempt 
caladan (config-if) #standby 1 track s0 


When a member of an HSRP group goes from the standby state to the active state, the following 
message is generated: 


01:10:14: SSTANDBY-6-STATECHANGE: Standby: 1: EthernetO state Speak 
-> Standby 

01:10:14: SSTANDBY-6-STATECHANGE: Standby: 1: EthernetO state Standby 
-—> Active 


To configure giedi_prime, you must set the standby group to be the same as caladan, which is 
standby group 1. You also must use the same virtual IP address as caladan. The use of the preempt 
argument will allow giedi prime to become the primary router, if that router's priority exceeds 
caladan's. Perhaps the most important command is the priority command. On the primary router, 
you have a priority of 105 and tracking on the serial interface. The priority of the primary router, 
caladan, will be 95 if it loses its serial interface. Therefore, the priority of the secondary, giedi_ prime, 
needs to be greater then 95. In this example, you will use 101. A value of 101 also provides the 
router with a higher priority than any new routers that might be added to the network with a default 
priority of 100. 


Example 16-2 demonstrates the configuration of giedi prime. 


Example 16-2 Configuring HSRP on the Secondary Route 


giedi_prime (config) #interface ethernet 0 
giedi_prime(config-if) #standby 1 ip 172.16.1.1 
giedi_prime(config-if) #standby 1 priority 101 
giedi_prime (config-if) #standby 1 preempt 
giedi_prime(config-if) #standby 1 track s0 


To verify the functionality of HSRP, use the show standby command. This command shows which 
router is primary, tells whether it can preempt, and gives the virtual IP and MAC addresses used in 
that group. Example 16-3 illustrates the show standby command on caladan, the primary router, 
and giedi prime, the secondary router. 


Example 16-3 show standby Command Output for the Primary and 
Secondary Routers 
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caladan#show standby 
EthernetO - Group 1 


‘~ active=Primary router 
Hellotime 3 holdtime 10 
Next hello sent in 00:00:02.496 
Hot standby IP address is 172.16.1.1 configured virtual IP address 


Active router is local 
Standby router is 172.16.1.3 expired 
Standby virtual mac address is 0000.0c07.ac01 
Tracking interface states for 1 interface, 1 up: 
Up Serial0 
caladan# 


giedi_prime#show standby 
EthernetO - Group 1 
Hellotime 3 holdtime 10 
Next hello sent in 00:00:02.540 
Hot standby IP address is 172.16.1.1 configured 
Active router is 172.16.1.2 expires in 00:00:09 


Tracking interface states for 1 interface, 1 up: 
Up Serial0O 
giedi_prime# 


To add authentication, simply add the standby 1 authentication password command under the 
Ethernet interface. Be sure that all routers in the group are authenticating. Example 16-4 shows the 
configurations in their entirety. 


Example 16-4 caladan 


hostname caladan 

! 

<<<text omitted>>> 

! 

interface Ethernet0O 

ip address 172.16.1.2 255.255.255.0 

‘this is added by the router when standby is enabled 

no ip directed-broadcast 

standby 1 priority 105 

standby 1 preempt 

“cisco is the password and is case sensitive 

standby 1 ip 172.16.1.1 

standby 1 track Serial0O 

! 
interface Serial0 

ip address 172.16.10.2 255.255.255.0 

no ip directed—-broadcast 

encapsulation frame-relay 

no ip mroute-cache 

no fair-queue 

frame-relay map ip 172.16.10.1 21 broadcast 
frame-relay map ip 172.16.10.3 21 broadcast 
! 
router eigrp 2001 


network 172.16.0.0 
! 
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hostname giedi_prime 
! 


<<<text omitted>>> 
! 
interface Ethernet0O 
ip address 172.16.1.3 255.255.255.0 
no ip redirects 
‘influence EIGRP, to not load-share 
standby 1 priority 101 
standby 1 preempt 
‘cisco is the password and is case sensitive 
standby 1 ip 172.16.1.1 
standby 1 track Serial0O 
! 
interface Serial0O 
ip address 172.16.10.3 255.255.255.0 
encapsulation frame-relay 
no fair-—queue 
frame-relay map ip 172.16.10.1 31 broadcast 
frame-relay map ip 172.16.10.2 31 broadcast 
! 
router eigrp 2001 


network 172.16.0.0 
! 
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The "Big show" and "Big D" for HSRP 


Still building on the first example, this section demonstrates the use of the show and debug 
commands for HSRP: 


show standby {brief | interface} 
debug standby 


The show standby command shows whether this interface is in standby mode or active 
mode. Active mode indicates that interface or router is the primary, while standby indicates 
that it's the secondary or backup interface or router. The show standby command also 
shows the hello timers, virtual MAC address in use, and any tracking information. Example 


16-5 lists the output from the show standby command on the caladan router. 


Example 16-5 show standby Command Output 


caladan#show standby 

EthernetO — Group 1 
Local state is Active, priority 105, may preempt 
Hellotime 3 holdtime 10 
Next hello sent in 00:00:02.496 
Hot standby IP address is 172.16.1.1 configured 
Active router is local 
Standby router is 172.16.1.3 expired 
Standby virtual mac address is 0000.0c07.ac01 
Tracking interface states for 1 interface, 1 up: 

Up Serial0O 
caladan# 


The debug standby command shows hello timer and hold timer settings. In addition, this 
command displays standby group information, such as which router is active and what the 
priorities are for the active and standby routers. Example 16-6 lists the output from the 


debug standby command, as seen on giedi prime. 


Example 16-6 Edebug standby Command Output for giedi prime 


giedi_prime#debug standby 

SB1l:EthernetO Hello in 172.16.1.2 Active pri 105 hel 3 hol 10 ip 172.16.1.1 
SB1:EthernetO Hello out 172.16.1.3 Standby pri 95 hel 3 hol 10 ip 172.16.1.1 
SB1:EthernetO Hello in 172.16.1.2 Active pri 105 hel 3 hol 10 ip 172.16.1.1 
SB1:EthernetO Hello out 172.16.1.3 Standby pri 95 hel 3 hol 10 ip 172.16.1.1 
SB1:EthernetO Hello in 172.16.1.2 Active pri 105 hel 3 hol 10 ip 172.16.1.1 
SB1:EthernetO Hello out 172.16.1.3 Standby pri 95 hel 3 hol 10 ip 172.16.1.1 
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Lab 33: Configuring HSRP, Tracking, and Asymetrical Routing—Part | 


Practical Scenario 


HSRP is an effective way to provide a fault-tolerant default gateway for TCP/IP. HSRP is mostly 
deployed in IP environments, where there are IP hosts with static default gateways. If there is 
router redundancy on the network, IP clients will still forward IP packets to the default gateway 
address, even if that default gateway router is down. There can still be a valid path out of the 
network, but the clients will fail because they know only how to forward packets to the default 
gateway. In these cases, HSRP provides a gateway address that can be shared among many 
routers, thereby closing the client loophole in redundant networks. 


Lab Exercise 


The 4th Army Com Net runs a Frame Relay network between Headquarters Company and Charlie 

Company. The workstations at Charlie Company are IP-based and require uninterrupted access to 
the headquarters master and backup server. The data passed between the companies is critical; if 
one router fails, the other router should resume its function. Use the following parameters as your 
design guidelines: 


e The workstations at Charlie Company are IP-based. They have static default gateways 
configured pointing to 10.25.61.3. Configure the network so that the workstations have 
uninterrupted access to headquarters_co, even upon failure of the charlie_1 or charlie _2 
routers; charlie_1 should be the primary router. 

e Ifthe charlie_1 or charlie_2 serial interface fails, ensure that the router is not the primary 
router. 


Lab Objectives 


e Configure the network as depicted in Figure 16-2. Use RIP V2 as the routing protocol. 
Configure RIP to perform asymmetrical routing with the primary router in HSRP. That is, if 
charlie_1 is the primary router, traffic should flow from the workstations to charlie_1, to 
headquarters_co, and back down through charlie_1 to the workstations. Traffic should not 
flow from the headquarters_co router to charlie_2 router, unless charlie _2 is the active 
HSRP router. 


Figure 16-2. 4th Army Com Net 
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Configure HSRP between charlie_1 and charlie_2. Configure the charlie_1 router to be the 
primary router for HSRP. 

Configure tracking on the serial interfaces. 

Optional: Improve the design of the Charlie Company network so that it operates more 
efficiently in an HSRP environment by using EIGRP as the routing protocol. 


Equipment Needed 


Four Cisco routers, three to serve as routers in the network, and one to serve as the frame 
switch. The frame switch will need to have three serial ports. The routers should be 
connected through V.35 back-to-back cables or in a similar manner. 

Two LAN segments, provided through hubs or switches. 

Optional: Two IP workstations, one to serve as a Charlie Company workstation and one to 
serve as the headquarters servers. 


Physical Layout and Prestaging 


Connect the hubs and serial cables to the routers as shown in Figure 16-2. Configure a 
Frame Relay switch in a multipoint configuration so that it provides PVC from 
headquarters_co to charlie_1 and charlie_2. The diagram does not show the frame switch 
or the frame switch configuration. 

Connect the two Ethernet hubs to the routers to form two LAN segments, as shown in 
Figure 16-2, with one segment connecting charlie_1 to charlie_2 and the other segment 
off of headquarters _co. 

Connect and configure two IP-based workstations, as shown in Figure 16-2, with the 
default gateway set to 25.100.61.3. 

Configure the headquarters_co router as shown with RIP version 2 as the routing protocol. 
Optional: Improve the design of the Charlie Company network so that it operates more 
efficiently in an HSRP environment by using EIGRP as the routing protocol. sae 


1040 


Lab 33: Configuring HSRP, Tracking, and Asymetrical Routing—Part 
ll 


Lab Walkthrough 


After completing the physical installation and the Frame Relay switch configuration, you should 
establish 1P connectivity among all the routers. Example 16-7 lists the Frame Relay 
configuration used in this lab. 


Example 16-7 Frame Relay Switch Configuration 


hostname frame_switch 

! 

frame-relay switching 

! 
<<<text omitted>>> 

! 

interface Serial0 

no ip address 

encapsulation frame-relay 

no fair-—queue 

clockrate 148000 

frame-relay intf-type dce 

frame-relay route 131 interface Seriall 31 
frame-relay route 121 interface Serial3 21 
! 

interface Seriall 

no ip address 

encapsulation frame-relay 

clockrate 148000 

frame-relay intf-type dce 

frame-relay route 31 interface SerialO 131 
! 

interface Serial2 

no ip address 

shutdown 

! 

interface Serial3 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay intf-type dce 

frame-relay route 21 interface SerialO 121 


Beginning with the headquarters _co router, configure the IP addresses of Ethernet and serial 
interfaces. Because you are configuring a multipoint Frame Relay network, you should use 
frame-relay map statements. Make the map statements point to the IP address of charlie_1 
and charlie 2, like the following: 


frame-relay map ip 25.100.10.2 121 broadcast 
frame-relay map ip 25.100.10.3 131 broadcast 
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Next, configure RIP Version 2 (RIP-2) as the routing protocol, as done in Example 16-8. RIP-2 is 
configured by adding the version 2 argument under the routing protocol. In this model, you will 
also added the distance argument. The distance argument will point a primary route to 
charlie_1; charlie_2 has an administrative distance of 125, which is 5 higher than a normal RIP 
distance of 120. This will force all outbound traffic to first go to the charlie_1 router, and the 
network to have asymetrical routing. 


Example 16-8 RIP-2 Configuration 


router rip 

version 2 

network 25.0.0.0 

distance 125 0.0.0.3 255.255.255.0 


The same set of commands will be needed on all routers in the 4th Army Com Net that are not 
running Cisco |OS Software Release 12.0. Next, configure the serial and Ethernet interfaces to 
send and receive RIP-2 updates by using the following commands: 


ip rip send version 2 
ip rip receive version 2 


Again, these same statements will be used on all the routers in 4th Army Com Net. 


When you are finished with the configuration for the headquarters_co router, it will look like 
Example 16-9. 


Example 16-9 Configuration of the headquarters_co Router 


hostname headquarters_co 
! 
interface Ethernet0O 
ip address 25.100.6.1 255.255.255.0 
ip rip send version 2 
ip rip receive version 2 
media-type 10BaseT 
! 
interface Serial0 
ip address 25.100.10.1 255.255.255.0 
ip rip send version 2 
ip rip receive version 2 
encapsulation frame-relay 
no ip mroute-cache 
frame-relay map ip 25.100.10.2 121 broadcast 
frame-relay map ip 25.100.10.3 131 broadcast 
! 
<<<<text omitted>>> 
! 
router rip 
version 2 
network 25.0.0.0 


distance 125 0.0.0.3 255.255.255.0 
! 


headquarters_co# 
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Moving on to the IP configuration of the Charlie Company routers, you should begin by adding 
IP addresses to the Ethernet and serial interfaces of each router. As mentioned previously, each 
router will also need to be configured for RIP-2. Follow the same steps as previously noted for 
the RIP-2 configuration. Because this is a multipoint Frame Relay network, you will also need to 
add frame-relay map statements. When you are finished with the IP configuration for each 
router, the configurations should resemble Example 16-10. 


Example 16-10 charlie_1 and charlie_ 2 1P Configurations 


hostname charlie_1 
! 
<<<text omitted... 
! 
interface Ethernet0O 
ip address 25.100.61.1 255.255.255.0 
no ip directed-—broadcast 
ip rip send version 2 
ip rip receive version 2 
! 
interface Serial0O 
ip address 25.100.10.2 255.255.255.0 
no ip directed-—broadcast 
ip rip send version 2 
ip rip receive version 2 
encapsulation frame-relay 
no ip mroute-cache 
frame-relay map ip 25.100.10.1 21 broadcast 
frame-relay map ip 25.100.10.3 21 broadcast 
frame-relay lmi-type cisco 
! 
<<<text omitted>>> 
! 
router rip 
version 2 
network 25.0.0.0 
! 
<<<text omitted>>> 
charlie_1# 


hostname charlie_2 
! 
interface Ethernet0O 
ip address 25.100.61.2 255.255.255.0 
ip rip send version 2 
ip rip receive version 2 
! 
interface Serial0O 
ip address 25.100.10.3 255.255.255.0 
ip rip send version 2 
ip rip receive version 2 
encapsulation frame-relay 
frame-relay map ip 25.100.10.1 31 broadcast 
frame-relay map ip 25.100.10.2 31 broadcast 
! 
<<<text omitted>>> 
router rip 
version 2 
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network 25.0.0.0 
! 


After establishing end-to-end IP connectivity, you can begin to configure HSRP. Following the 
steps for HSRP, you must first define the HSRP or virtual router IP address. All the workstations 
at Charlie Company point to a default gateway address of 25.100.61.3. Therefore, this will be 
your HSRP address. Each router will need the preempt and the priority statements as well. 


Because charlie_1 will be the primary router, you should set its priority above the default of 
100. Before setting the priority, take into consideration the circumstance at which you will want 
this router to not be the primary. In this model, you want charlie_1 to be the primary until the 
link fails. If you set the priority of charlie_1 to 105 and use the default tracking cost of the serial 
interfaces on charlie_1 and charlie_2 of 10, this will put the priority at 95 upon the loss of a 
serial link. Therefore, you will need to set the priority of charlie_2 to greater then 95 but less 
then 105. Example 16-11 demonstrates the configuration of the charlie_1 router. 


Example 16-11 Configuration of charlie_ 1 Router for HSRP 


charlie_l#conft t 

Enter configuration commands, one per line. End with CNTL/Z. 
charlie_1 (config) #interface ethernet 0 

charlie_1(config—if) #standby 1 ip 25.100.61.3 
charlie_1(config—if) #standby 1 preempt 

charlie_1(config—if) #standby 1 priority 105 


04:08:11: SSTANDBY-6-STATECHANGE: Standby: 1: EthernetO state Speak => Stan 
dby 
04:08:11: SSTANDBY-6-STATECHANGE: Standby: 1: EthernetO state Standby -—> Active 


charlie_1(config—if) #standby 1 track serial 0 


When configuring HSRP, a state change message will be sent when HSRP becomes active. When 
this is complete, verify the HSRP configuration with the show standby ethernet 0 command, 
as demonstrated in Example 16-12. Look for the local state to be "active," and make sure that 
the active router is "local." Also ensure that the host standby IP address is the one that you 
configured. 


Example 16-12 Status of the Primary Router 


charlie_l#show standby ethernet 0 
EthernetO -— Group 1 


Hellotime 3 holdtime 10 
Next hello sent in 00:00:00.678 
Hot standby IP address is 25.100.61.3 configured 


Standby router is 25.100.61.2 expired 
Standby virtual mac address is 0000.0c07.ac0O1 
Tracking interface states for 1 interface, 1 up: 
Up SerialOd 
charlie_l# 


The configuration of the charlie_2 router will be identical to the configuration of the charlie_1 
router, except for the priority, which can be left at the default of 100. Setting the priority at 101 
is still preferred, to ensure that this router is second only to the primary. This also helps to 
break any possible "tie-breakers" with new routers that might be added to the HSRP group in 
the future. When this is complete, verify HSRP on charlie_2 with the show standby Ethernet 0 
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command, as listed in Example 16-13. 


Example 16-13 Status of the Standby Router 


charlie_2#show standby ethernet 0 
EthernetO -— Group 1 


Hellotime 3 holdtime 10 
Next hello sent in 00:00:01.336 


Tracking interface states for 1 interface, 1 up: 
Up SerialO 
charlie_2# 


In this example, you want to verify that the local state is standby and that it may preempt, or 
take over as the active router, if priority warrants it. Example 16-14 shows the HSRP 


configuration for both Ethernet interfaces on charlie_1 and charlie_2. 


Example 16-14 HSRP Configurations for charlie_1 and charlie_2 


charlie _1# 

interface Ethernet0O 

ip address 25.100.61.1 255.255.255.0 
o ip redirects 

no ip directed—-broadcast 
ip rip send version 2 

ip rip receive version 2 
standby 1 priority 105 
standby 1 preempt 
standby 1 ip 25.100.61.3 
standby 1 track Serial0O 


charlie _2# 
interface Ethernet0O 

ip address 25.100.61.2 255.255.255.0 
no ip redirects 

ip rip send version 2 

ip rip receive version 2 

standby 1 priority 101 

standby 1 preempt 

standby 1 ip 25.100.61.3 

standby 1 track Serial0O 


To test the HSRP configuration for functionality, attach an | P-based workstation, as shown in 
Figure 16-2. Make sure that the default gateway on the workstation is pointing to 25.100.61.3. 
This workstation should be capable of pinging the IP address of the EO port of the 
headquarters _co router or the headquarters servers, if you have them configured. To test the 
failover process, go to the frame switch and disable the serial interface attached to the charlie_1 
router. HSRP will note that the interface is down and will subtract the cost associated with the 
interface—in this case, the default of 10. This will put the priority of charlie_1 at 95, less than 
charlie_2, so charlie_2 should be active. You can verify the failover by performing traceroute 
functions on the workstations and by using the show standby interface command. Example 
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16-15 lists the show standby interface output on charlie_2 after you have downed the frame 
switch serial interface attached to charlie_1. Note the state change from standby to active. 


Example 16-15 show standby Command Output After Failover 


charlie_2#show standby ethernet 0 
EthernetO — Group 1 


Hellotime 3 holdtime 10 
Next hello sent in 00:00:00.952 
Hot standby IP address is 25.100.61.3 configured 


Standby router is 25.100.61.1 expires in 00:00:07 
Tracking interface states for 1 interface, 1 up: 
Up SerialOd 
charlie _2# 


Also ensure that IP routing is working by issuing test pings from the workstations and by 
looking at the routing table of headquarters_co router. Example 16-16 lists the routing table of 
headquarters_co, before and after the failover. It first shows RIP updates coming from 
25.100.10.2, the primary router. After failover, the routing updates start to come from 
25.100.10.3, with an administrative distance of 125. 


Example 16-16 IP Route Table Before and After Failover Tests 


headquarters_co#show ip route 
Codes: C -— connected, S -— static, I - IGRP, R —- RIP, M —- mobile, B —- BGP 
<<<text omitted>>> 


25.0.0.0/24 is subnetted, 3 subnets 
Cc 25.100.10.0 is directly connected, SerialO 
c 25.100.6.0 is directly connected, Ethernet0 
headquarters_co# 
! AFTER WE DOWN THE FRAME INTERFACE WE HAVE THE FOLLOWING: 
headquarters_co#show ip route 
Codes: C -—- connected, S —- static, I - IGRP, R —- RIP, M —- mobile, B — BGP 
<<<text omitted>>> 


Gateway of last resort is not set 


25.0.0.0/24 is subnetted, 3 subnets 


€ 25.100.10.0 is directly connected, Serial0O 
Cc 25.100.6.0 is directly connected, Ethernet0O 
headquarters_co# 


headquarters_co#show ip route 
Codes: C -— connected, S —- static, I - IGRP, R — RIP, M —- mobile, B — BGP 
<<<text omitted>>> 


Gateway of last resort is not set 
25.0.0.0/24 is subnetted, 3 subnets 


Q 


25.100.10.0 is directly connected, Serial0d 
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e 25.100.6.0 is directly connected, Ethernet0 
headquarters_co# 


The time that it takes for RIP-2 to converge from the primary router to the backup router can 
be a few minutes. This leads to the optional part of the lab. To improve the design of the 4th 
Army Com Net, you could change the routing protocol from RIP-2 to EIGRP or OSPF. By 
switching the routing protocol, |P convergence can happen much quicker. This, in turn, better 
supports the functionality and purpose of HSRP. 


In this model, you use EIGRP because the migration from RIP to EIGRP can be quite easy. The 
best way to migrate to EIGRP is simply to add the router eigrp command with an autonomous 
system and network address. Because the administrative distance of EIGRP is less than that of 
RIP, the routing table will automatically converge from RIP to EIGRP, as shown in Example 16- 
17. 


Example 16-17 IP Routing Table of headquarters_co Router on EI GRP 


headquarters_co#show ip route 

Codes: C -— connected, S —- static, I - IGRP, R —- RIP, M —- mobile, B — BGP 
D — EIGRP, EX — EIGRP external, O — OSPF, IA —- OSPF inter area 

<<<text omitted>>> 


Gateway of last resort is not set 


25.0.0.0/24 is subnetted, 3 subnets 


D 25.100.61.0 [90/2195456] via 25.100.10.2, 00:00:02, Seriald 
C 25.100.10.0 is directly connected, Serial0O 
c 25.100.6.0 is directly connected, Ethernet0 


headquarters_co# 


To influence the routes advertised by EIGRP, add a DELAY to the Ethernet segment of charlie 2. 
This way, when EIGRP reports that route to headquarters _ co, it will be weighted. This then will 
cause EIGRP to have a preferred route to the subnet 25.100.61.0/24, through the charlie_1 
router. The delay should be added to the Ethernet interface instead of the serial interface 
because traffic destined for the headquarters master server from charlie_2 should leave through 
the serial interface. If the delay is put there, EIGRP will want to route this traffic through the 
Ethernet port to charlie_1 first. When your EIGRP configuration is complete, remove the RIP 
portions of the configuration with the no router rip command. This command will remove all 
RIP-related statements. 
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Chapter 17. Configuring Network Time Protocol (NTP) 
and Simple Network Time Protocol (SNTP) 


Bob poured feverishly over the latest trace of the chronic link problem. There was a strong 
chance that it was this same problem that they had experienced just one week earlier. Bob 
wasn't his real name; it was a name that all the guys called him because he was the "new 
guy." Bob knew almost every acronym in the Telco industry, and he also knew that the ATM 
was indeed faster then Ethernet. In the middle of his spaghetti network, he had finally found 
a "smoking gun." He would finally prove his worth to the whole group by cracking this chronic 
problem. Carefully continuing down the trace, he came to two places where the link had 
failed: The timestamps read 12:01:21 OCT 18, 1999 and 11:23:40 OCT 18, 1999. Quickly 
turning to the log of the remote site, Bob found 105 failures, all dated from 11:57:42.079 
UTC Mar 1 1993 to 03:32:12.022 UTC Mar 17. HMmmmmmm ... 


Sadly, Bob would have to wait for another day and unfortunately, another failure, to correlate 
his findings. The next time, however, it will be different: Bob is going to add the Network 
Time Protocol (NTP) to his acronym list. 
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NTP Overview 


NTP was designed to provide an accurate and stable clock to remote sources across an 
unmanaged, global Internet environment. Before NTP, other protocols such as Daytime 
protocol, Time protocol, and |CMP timestamp provided this service. Digital Time Service 
(DTS) accomplished many of the same objectives as NTP. However, NTP provides for the use 
of stratum information in clock selection and provides an accurate compensation for inherent 
clock frequency errors. DTS does not use a stratum or compensate for inherent frequency 
errors. 


The concept of a stratum was conceived directly from the telephone industry, under BELL 86. 
The accuracy of each NTP server was defined with a stratum number. The most accurate 
server stratum starts at 1 and increments from there. The implementation of a stratum 
allows NTP to select from multiple clock sources and judge which one to synchronize with. 


The stratum value of 1 requires the accuracy provided by atomic clocks. You will not be able 
to configure a Cisco router to supply or have a stratum 1 clock, for obvious reasons. 


NOTE 


Atomic clocks have oscillators that can maintain extremely precise frequencies 
that correspond to natural phenomenon. The earliest and ultimate oscillators are 
our celestial bodies. But because of their vastness and our lack of scientific 
knowledge about them, scientists base atomic clocks on the orbital states of an 
electron instead of the orbital states of planets and our solar system. The atom 
provides a stable and accurate model on which scientists can perform accurate 
measurements. Atomic oscillators are based on the transitions of hydrogen, 
cesium, and rubidium atoms. 


NOTE 


To test NTP, | used the shareware TARDIS2000 V1.2, available at c/net's 
DOWNLOAD.COM or http://download.cnet.com. Two public NTP/SNTP clocks' 


addresses that you can use in your models are zeus.tamu.edu or 
128.194.103.14, and tmc.edu or 128.249.1.1. 


After you synchronize with them, most atomic clocks provide a stratum level of 3 or greater 
to the client. Consider 3 to be a highly reliable stratum level when using NTP. 


NTP was specifically designed to produce three products: 


e Clock offset— Clock offset is the amount by which to adjust the local clock so that it 
corresponds to the reference clock. 


e Round-trip delay— Round-trip delay makes it possible for a reference clock to 
launch a message to arrive back at the reference clock at a specific time. 
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e Dispersion— Dispersion is the maximum error of the local clock relative to the 
reference or NTP server. 


These products are all produced in relation to the local clock, and they use Greenwich Mean 
Time, UTC, or Coordinated Universal Time as a common reference in time. If the local clock is 
unreliable, it will affect NTP synchronization, as well as the values provided by NTP, which 
also provides these values with a relatively simple data flow and little overhead to the 
network. NTP accomplishes this by using User Datagram Protocol (UDP) port 123. Data 
integrity is provided by UDP checksums; no flow control or retransmission facilities are 
provided or necessary. 


NTP can be used in a variety of ways. Perhaps the most common use of NTP is for an NTP 
client to obtain a valid clock from an external source through IP. If multiple clients are 
synchronizing off the same source, this allows for entire network synchronization. Network 
clock synchronization can provide several useful functions: 


e As the tragic story of Bob illustrates, NTP can be a useful protocol when trying to 
correlate network anomalies, such as link or neighbor failures. 

e Network clock synchronization helps to correlate time accurate logs and debug 
information from multiple routers. 

e Network-management platforms, such as CiscoWorks and HP OpenView, will be more 
effective and accurate in reporting network statistics. 


NTP was first described in RFC 958, but since its first release, it has evolved many times. NTP 
version 3 is the dominant version of NTP today. RFC 1305 outlines NTP and obsoletes RFCs 
1119, 1059, and 958. RFC 2030 outlines the Simple Network Time Protocol (SNTP), which is 
an adaptation of NTP Version 3. The only significant change in SNTP Version 4 is its 
adaptation to properly interpret an |Pv6 header and OSI addressing. 


NOTE 


You can find all RFCs online at www.isi.edu/in-notes/rfcxxxx.txt, where xxxx is 
the number of the RFC. 
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Configuring NTP 


NTP can be configured to support a number of different environments. The following are the most common implementations of 
NTP and are the ones that you will be configuring in this chapter: 


e NTP broadcast client mode— The router can be configured to passively listen for NTP broadcasts, avoiding a static entry 
to one specific time server. 


e NTP static client mode— The router can be configured to listen and exchange messages between statically configured 
NTP servers. 


e NTP master mode— The router can be configured as an NTP server forwarding NTP broadcasts. 


e NTP peer associations— The router can be configured to form an NTP peer association with another router. The router 
can either synchronize to the other system or allow the other system to synchronize to it. 


e NTP options and time-related configurations— NTP options include perform authentication and setting the calendar. 
Time-related options include setting daylight saving time and the current time zone. 


Configuring NTP Broadcast Client Mode 


Cisco routers can be configured to receive NTP broadcasts on an interface-by-interface level. This type of configuration should be 
used in LAN environments and can be used to avoid the need to statically configure multiple NTP servers. To configure a router to 
receive NTP broadcasts, use the ntp broadcast client command under the interface nearest the NTP server or on the interface 
receiving the NTP broadcast. Figure 17-1 shows a LAN configured with an NTP server. The NTP server has a stratum of 5 and an 
IP address of 206.191.241.44. 


Figure 17-1. NTP Broadcast Client 
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Example 17-1 provides the configuration for the router to receive NTP broadcasts on its Ethernet 0 interface. 


Example 17-1 Configuring an NTP Broadcast Client 


ntp_client (config) #int ethernet 0 
ntp_client (config-if)#ntp broadcast client 
ntp_client (config-if) #exit 

ntp_ 


To verify that the clock has synchronized, use the show ntp associations and show ntp status commands. Examples 17-2 and 
17-3 demonstrate the use of these commands on the ntp_client router. 


Example 17-2 The show ntp associations Command 


ntp_clent#show ntp associations 


address ref clock st when poll reach delay offset disp 
* master (synced), # master (unsynced), + selected, - candidate, ~ configured 
ntp_clent# 


Example 17-2 highlights the key values to look at. When NTP is synchronized, an asterisk (*) denotes that the router has received 


UDP packets from the address listed immediately after the asterisk and that the router has synchronized with that NTP server. 
The st field indicates that the clock source is a stratum 5 clock. The ref clock field (reference clock) indicates the clock that the 
NTP source synchronized to. If the number is 127.127.7.1 and the device is a Cisco router, the clock is synchronized with itself. 


Example 17-3 The show ntp status Command 


ntp_clent#show ntp status 


nominal freq is 250.0000 Hz, actual freq is 250.0093 Hz, precision is 2**19 
reference time is BCF2162C.BDFOEE87 (09:33:16.741 CSTDST Wed Jun 14 2000) 
clock offset is -91.9576 msec, root delay is 4.14 msec 

root dispersion is 135.64 msec, peer dispersion is 43.67 msec 

ntp_clent# 


The first line in Example 17-3 provides a clear indication that the clock has synchronized from an address of 206.191.241.44. 


Here, the stratum has been adjusted to one greater than the original stratum of the master clock. In this example, the router has 
some optional time-related commands configured. We have set daylight savings time and have set an offset from UTC of six 
hours. These options will be covered in later sections. 


Configuring NTP Static Client Mode 


Another way to configure the NTP client is to statically map it to a specific time server. A static NTP server should be used when 
you want to receive an NTP broadcast from a specific host. An example is when you want to point to the Internet and synchronize 
the router with one of the atomic clocks on it. 


Building on the first model, let's configure another NTP client on the same router, pointing to an atomic clock on the Internet. At 
TMC.EDU, or 128.249.1.1, is an atomic clock that you can use as a NTP server. Figure 17-2 illustrates the new NTP configuration 


performed in Example 17-4. 


Figure 17-2. NTP Static Client 
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Example 17-4 Configuration of the ntp_ client Router 


hostname ntp_client 
! 

! 
<<<text omitted>>> 
! 
interface Ethernet0 


ip address 206.191.241.43 255.255.255.248 
no ip directed-broadcast 


(REP esesdeaervetzens 

! 

<<<text omitted>>> 

! 

ntp clock-period 17179279 = ‘This is added by the router 

To configure the router to receive its NTP broadcast from a specific host, use the ntp server a.b.c.d command. This is a global 


command, and the router can have multiple NTP servers configured at any one time. 


You can now perform the same show commands, show ntp assoc and show ntp status, to verify the synchronizpyar 


Example 17-5 shows NTP slowly converging to the new NTP server. RFC 1305 points out that clock synchronization requires long 
periods and multiple comparisons to maintain accurate time. The time for synchronization to occur will range, depending on 
multiple factors. Be prepared to wait a while for clock synchronization; however, if the clocks do not synchronize in an hour or 
sooner, you might want to review your NTP design. In the labs and examples presented here, NTP synchronized in less than five 
minutes. 


Example 17-5 The show ntp assoc and show ntp status Command 


ntp_client#show ntp stat 


nominal freq is 250.0000 Hz, actual freq is 250.0096 Hz, precision is 2**19 
reference time is BCF258FA.69DAF6F5 (14:18:18.413 CSTDST Wed Jun 14 2000) 
clock offset is -16.8153 msec, root delay is 4.06 msec 

root dispersion is 409.61 msec, peer dispersion is 392.78 msec 

ntp_client# 

ntp_client#show ntp ass 


address ref clock st when poll reach delay offset disp 
‘NTP configured but no synced 

* 206.191.241.44 123.194,103.14 5 46 8192 a) 4.1 =16.82 392.8 

* master (synced), # master (unsynced), + selected, - candidate, ~ configured 


ntp_client# 


ntp_client#show ntp ass 


address ref clock st when poll reach delay offset disp 

— SaEESwe 
206.191.241.44 128.194.103.14 5 26 8192 77 4.1 T5e2s 20.0 
* master (synced), # master (unsynced), + selected, - candidate, ~ configured 


ntp_client#show ntp stat 


nominal freq is 250.0000 Hz, actual freq is 250.0093 Hz, precision is 2**19 
reference time is BCF26309.F694401F (15:01:13.963 CSTDST Wed Jun 14 2000) 
clock offset is 30.7128 msec, root delay is 151.06 msec 

root dispersion is 97.17 msec, peer dispersion is 26.05 msec 

ntp_client# 


Configuring NTP Master Mode 


Cisco routers can also use NTP to function as authoritative NTP servers. When configuring a router as an NTP server, you should 
take care when setting the stratum level. This value should range somewhere between 6 and 15; the default is 8. The clocks in 
the mid- and upper-class routers, such as the 36xx, 47xx, and 7k series routers, are much more reliable and provide a calendar 
function. Use these types of routers for your NTP servers. 


To configure a Cisco router as an authoritative NTP server, use the ntp master [stratum_number]command in global 
configuration mode. Figure 17-3 shows a Cisco 4700 router as the NTP master and a Cisco 2500 router as the NTP client. The 


4700 is a good choice as the NTP server because it has a more reliable clock than the 2500 router. You will use the ntp master 
command on the server, and the client can be configured as either a static client or a broadcast client. 


Figure 17-3. NTP Configuration: Using a Router as an NTP Server 
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Example 17-6 illustrates the configuration of an NTP master and an NTP static client. 


Example 17-6 Configuration of an NTP Master and Client 


ntp_server#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
ntp_server (config) #ntp master 7 

ntp_server (config) #exit 

ntp_server# 


ntp_client#conf t 

Enter configuration commands, one per line. End with CNTL/Z. 
ntp_client (config) #ntp server 10.150.10.3 

ntp_client (config) #exit 

ntp_client# 


Use the show ntp status to verify that the clock is synchronized, and use show ntp associations for detailed information on 
the clock/server that the router has synchronized with. Example 17-7 shows the output for these commands. Again, you are 
looking for the clock to be synchronized and for the reference address to be 10.150.10.3, which is the NTP master. 


Example 17-7 show ntp status and show ntp associations Command Output 


ntp_client#show ntp status 


nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**19 

reference time is BD13BB90.AE4D80D0 (03:03:44.680 UTC Mon Jul 10 2000) 

clock offset is 1.2757 msec, root delay is 3.78 msec 

root dispersion is 1.97 msec, peer dispersion is 0.67 msec 

ntp_client# 

ntp_client#show ntp associations 1055 


address ref clock st when poll reach delay offset disp 


* master (synced), # master (unsynced), + selected, - candidate, ~ configured 
ntp_client# 


Configuring NTP Peer Associations 


An NTP peer association is much like that of a static peer. An NTP association can be a peer association, meaning that it allows 
this system to synchronize to another system or allows the other system to synchronize to it. This type of NTP configuration can 
be deployed in the standard Cisco hierarchical three-layer network design practice (core, distribution, and access layers). At the 
core level reside NTP master servers, which can be routers or actual NTP servers. The distribution-level routers have a single peer 
to the core routers. The access-level routers, in turn, peer to the distribution routers. This keeps many NTP broadcasts, however 
slight they may be, from all going to the same host, yet it provides complete network time synchronization across the 
internetwork. If a peer loses synchronization, by the rules of NTP, it will not synchronize with any other external sources. 
Therefore, locate your central peers where a potential loss of physical connectivity makes it logical for the clock to become 
unsynchronized. 


In Figure 17-4, the access routers have a single NTP peer pointing to the distribution router's Ethernet segment. The distribution 
routers have a single NTP peer pointing to the core router. 


Figure 17-4. NTP Peer Associations 
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The core router could be initiating the time source or, in this case, synchronizing to a more reliable external time source. To 
configure NTP peers, use the ntp peer ip address command, in which the IP address is the NTP time source that you want to 
synchronize to. There is no need to put an ntp peer statement on both sides of the connection. The access routers in Figure 17-4 
will have a single ntp peer statement, as will the distribution and the core routers, each pointing only at the IP address where 
they want to get the time source. Example 17-8 lists the syntax needed to accomplish NTP peering for Figure 17-4. 


Example 17-8 NTP Peer Configurations for Figure 17-4 


Access routers: 
ntp peer 10.150.10.1 


Distribution router: 
ntp peer 10.150.10.3 


Core: routers 


ntp server 10.150.10.10 or 
ntp master 6 


Configuring NTP Authentication and Other Clock-Related Options 


NTP also provides Message Digest 5 (MD5) authentication of NTP packets for applications that require a secure timd O6ce. For 


applications that bill and track by the minute or the second, it is critical that a secure and reliable clock is kept across the 
network. Configuring MD5 authentication involves three steps: 


Step 1. Enable NTP authentication. Use the ntp authenticate global command. 


Step 2. Define authentication keys. Configure an MD5 password and an authentication key to use with it. Use the ntp 
authentication-key key_number md5 md5_ password global command. 


Step 3. Define a trusted key. Using the same key_number as in Step 2, define a trusted key that will be used among the 
routers when authenticating NTP. Use the ntp trusted-key key_ number command to accomplish this. 


Figure 17-5 shows two routers configured for NTP authentication. The ntp_t_server router is the NTP master. The ntp_t_client 
router is the NTP client. 


Figure 17-5. NTP Master and Client Configuration with MD5 Authentication 
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The ntp authentication commands for both routers will be identical. You must enable authentication to each router and then 
define the authentication and trusted keys. Example 17-9 demonstrates the commands needed to configure the NTP master; 


Example 17-10 demonstrates the commands needed for the client. 


Example 17-9 Configuring Authentication for NTP on the Master 


ntp_t_server (config) #ntp master 6 

ntp_t_server (config) #ntp authenticate 

ntp_t_server (config) #ntp authentication-key 3 md5 cisco 
ntp_t_server (config) #ntp trusted-key 3 


Example 17-10 Configuring Authentication for NTP on the Client 


ntp_t_client (config) #ntp server 10.150.10.3 
ntp_t_client (config) #ntp authenticate 

ntp_t_client (config) #ntp authentication-key 3 md5 cisco 
ntp_t_client (config) #ntp trusted-key 3 


Using the same show commands mentioned previously, show ntp status and show ntp associations, you can verify that NTP 
is synchronized as demonstrated in Example 17-11. 


Example 17-11 show ntp stat and show ntp assoc Command Output 


ntp_t_client#show ntp stat 


nominal freq is 250.0000 Hz, actual freq is 249.9990 Hz, precision is 2**19 1057 


reference time is BD15D137.C52F08AF (17:00:39.770 UTC Tue Jul 11 2000) 
clock offset is 1.4114 msec, root delay is 3.77 msec 

root dispersion is 1.46 msec, peer dispersion is 0.03 msec 
ntp_t_client#show ntp associations 


address ref clock st when poll reach delay offset disp 


* master (synced), # master (unsynced), + selected, - candidate, ~ configured 
ntp_t_client# 


Configure Clock and Time Zones 


Inherently critical to having a common clock across the network is having that clock correct and uniform. That includes setting the 
time zone and daylight saving time. The default time zone is UTC, or Greenwich Mean Time. NTP also can periodically update the 
calendar, if one is present on the router, as in the Cisco 3600, 7000, and higher-end series routers. 


To configure time-zone values, use the following commands from the global configuration mode: 


e clock timezone timezone_name [hours_plus_or_minus_from_UTC] [minutes_offset_from_UTC] 
e clock summertime summer_timezone_name [recurring] date] 
e ntp update-calendar 


When you configure a time zone, you can enter the time zone name, such as PAC or CST for Pacific and Central time accordingly, 
or you can make up a name. You can also set the hours (+23 to -23) and minutes offset from UTC time. When you configure 
daylight saving time with the clock summertime command, you can enter a time zone name that will appear when running in 
daylight saving mode. You also can configure any daylight saving offset or specifics that your local government has implemented. 
The default rules on daylight saving time is that the router or switch will advance the clock one hour on the first Sunday in April at 
2:00 a.m., and move the clock back one hour on the last Sunday in October at 2:00 a.m. 


Apply these commands to routers in Figure 17-5. Set the time zone on ntp_t_server to U.S. Central time, and enable daylight 
saving time. CST time is a -6 hour offset from Greenwich Mean Time, so you will want to adjust the offset accordingly. Example 
17-12 demonstrates how to set the master clock on Figure 17-5 to Central time. 


Example 17-12 Setting the Time Zone and Daylight Saving Time 


ntp_t_server (config) #clock timezone CST -6 
ntp_t_server (config) #clock summer-time CDT recurring 


Performing a show clock on the ntp_t_master router results in the output in Example 17-13. 


Example 17-13 show clock Command Output I ndicates Daylight Saving Time in Effect 


ntp_t_serverr#show clock 
13:44:49.063 CDT Tue Jul 11 2000 
ntp_t_server# 


Note that the CDT is the time zone name, which denotes that we are running on daylight saving time. 
TIP 


NTP does not pass time zone information in its updates. To configure the proper time zone, you must use the clock 
timezone command on all the routers in the network. | recommend setting all the clocks to UTC, the default, if the 
network is large or global. If the network is smaller, the routers should be set to the time zone that the core routers 
are in. Without a common time zone, problem and event correlation can be much more difficult. 


NOTE 


The ntp clock-period that appears in the router's configuration listing is added automatically into the router configs 
when NTP is enabled. It serves to jump-start the NTP frequency compensation when the router is rebooted. 
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Configuring the Simple Network Time Protocol (SNTP) 


On smaller routers that do not >support NTP, such as the Cisco 100x series, the 80x series, 
and other lower-end routers, you can deploy SNTP. However, SNTP lacks some of the 
enhanced features of NTP: It cannot be an NTP server, and it provides no authentication and 
statistics mechanisms. SNTP can be configured in two ways, much like NTP: 


e Configure the router to passively listen for SNTP broadcasts on a wire. 
e Statically map SNTP to a specific server. 


If both methods are configured, the router accepts a tie from a broadcast server, but it 
prefers time from the static server, assuming that the stratum levels are equal. 


To configure SNTP on the smaller Cisco platforms, use the following global commands: 


e sntp serverserver_IP_address— This command statically maps an SNTP server to the 
router for SNTP updates. It performs just like the NTP server command. 


e sntp broadcast client— This command passively listens for SNTP broadcast on the 
router interfaces. 


e show sntp— This command shows SNTP status. 


The example in this section uses a Cisco 804, called skynet_2, and an NTP server on its LAN 
interface, as illustrated in Figure 17-6. 


Figure 17-6. SNTP Configuration Topology 


1059 


skynet_2 


E0-IP-206.191.241.41/29 


Ethernet 
segment 


NTP server 
IP-206.191.241.44/29 


To configure this router to receive updates from an unknown source, simply add the sntp 
broadcast client configuration command. You will also add the appropriate time zone for 
the U.S. Central time and set daylight saving time. Example 17-14 demonstrates this process. 


Example 17-14 Configuring SNTP on a Cisco 804 Router 


skynet_2 (config) #sntp broadcast client 

skynet_2 (config) #elock timezone CST -6 

skynet_2 (config) #clock summer-time CDT recurring 
skynet_2 (config) #exit 
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skynet_2#show sntp 
SNTP server Stratum Version Last Receive 
206.191.241.44 14 3 00200339 Synced Bcast 


Broadcast client mode is enabled. 


skynet_2#show clock 
14:12:45.116 CDT Tue Jul 11 2000 


Note that the SNTP has synchronized to the server 206.191.241.44 with a stratum 14, 
without statically configuring it. The show clock command shows the clock to be in daylight 
saving time. 
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The "Big show" and "Big D" for NTP and SNTP 


You have already seen and used the three primary show commands for NTP and SNTP. Those 
commands are as follows: 


e show ntp status— This command provides detailed status of NTP synchronization, along 
with the three primary elements of NTP: delay, offset, and dispersion. 


e show sntp— This command displays whether SNTP is configured if it has not found a valid 
clock source. If SNTP is synchronized, this command displays the IP address and the 
stratum of the server. 


e show ntp associations [detailed]— This command displays any statically configured NTP 
peers, along with the clock selection and whether the peer is synchronized. 


Example 17-15 lists the output from the show ntp status command. The output details that you 


want to look for here are that the clock in synchronized, with a valid stratum, usually less then 16. 
You also need information about a reference clock. The clock offset, root delay, root, and peer 
dispersion should be relatively small numbers, in the millisecond range, when the clocks are 
synchronized. 


Example 17-15 show ntp status Command Output 


ntp_t_client#show ntp status 


nominal freq is 250.0000 Hz, actual freq is 249.9984 Hz, precision is 2**19 
reference time is BD1604F7.3618FFO7 (20:41:27.211 UTC Tue Jul 11 2000) “~~ correct 
clock offset is 0.3951 msec, root delay is 3.78 msec 


root dispersion is 0.44 msec, peer dispersion is 0.03 msec 
ntp_t_client# 


Example 17-16 lists the output from a show ntp status command, where the clock hasn't 
synchronized. Notice that the stratum is not set and no reference clock exists. 


Example 17-16 Bad Output from the show ntp status Command 


timex#show ntp stat 


nominal freq is 250.0000 Hz, actual freq is 250.0003 Hz, precision is 2**19 
reference time is BD15D99C.4AC66EEO (17:36:28.292 UTC Tue Jul 11 2000) 
clock offset is -0.1224 msec, root delay is 31.14 msec 

root dispersion is 1.45 msec, peer dispersion is 0.14 msec 

timex# 


Example 17-17 lists the output from the show sntp command. The relevant information to look for 


here is the IP address of the SNTP server, a valid stratum, and confirmation that the clock is 
synchronized. If no valid SNTP broadcasts are found, this command displays only that the SNTP 
client mode is enabled. 


Example 17-17 show sntp Command Output 
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skynet_2#show sntp 
SNTP server Stratum Version Last Receive 
206.191.241.44 14 3 00:00:44 Synced Bcast 


Broadcast client mode is enabled. 


Example 17-18 lists the output from the show ntp associations command. The key indicator is 
the *, which indicates that the master clock is synchronized and gives the IP address and stratum 
of that clock. The bottom of the example lists the extended version of this command, which 
includes information on delay, offset, and dispersion. The first line of the output provides a quick 
view of the primary NTP association. 


Example 17-18 show ntp associations Command Output 


timex#show ntp associations 
address ref clock st when poll reach delay offset disp 


* master (synced), # master (unsynced), + selected, - candidate, ~ configured 
timex# 
timex#show ntp associations detail 


ref ID 10.150.10.3, time BD160B37.3911241E (21:08:07.222 UTC Tue Jul 11 2000) 
our mode active, peer mode passive, our poll intvl 64, peer poll intvl 64 
root delay 3.78 msec, root disp 0.41, reach 377, sync dist 5.432 

delay 6.07 msec, offset -0.5087 msec, dispersion 0.09 

precision 2**19, version 3 

org time BD160B48.A2712FA3 (21:08:24.634 UTC Tue Jul 11 2000) 

rev time BD160B48.A3598FCA (21:08:24.638 UTC Tue Jul 11 2000) 

xmt time BD160B48.A19B718B (21:08:24.631 UTC Tue Jul 11 2000) 


filtdelay = 6.07 6.04 6.03 6.13 6.03 6.09 6.01 6.06 
filtoffset = =0..54 -0.41 -0.40 -0.43 -0.48 -0.43 -0.41 =0..39 
filterror = 0.02 01499 1397 2.94 3.92 4.90 Scns 6.85 
timex# 


Cisco provides many debugs for NTP, but perhaps the most useful one is debug ntp select. This 
debug shows the status of NTP peers, along with the packet exchange as it is occurring. Most of 
the other debugs indicate only when an event is triggered, such as debug ntp events and debug 
ntp sync. These display only information when state changes happen and give no indications of 
internal workings. 


Example 17-19 lists the output of the debug ntp select command, which indicates that the output 


packet is going to the NTP server 10.150.10.3, your configured clock. You also see the offset 
measured from the survivor clock, which indicates that the clocks have been compared. 


Example 17-19 debug ntp select Command Output 


03:42:37: NTP: nlist 1, allow 0, found 0, low —0.001984, high 0.002411 
03:42:37: NTP: candidate 10.150.10.3 cdist 96.002197 error 0.000305 
O3:422372 NIP: survivor 10.150.10.3 offset 0.000226, cdist 96.00220 


O3343323% NIP: nlist. 1, allow 0, found 0, Jows=0.001785,. high 02002151 
03:43:23: NTP: candidate 10.150.10.3 cdist 96.001968 error 0.000076 
03343323: NIP: survivor 10.150.10.3 offset 0.000185, edist 96.00197 


03:43:41: NTP: nlist 1, allow 0, found 0, low —0.002045, high 0.002411 
03:43:41: NTP: candidate 10.150.10.3 cdist 96.002228 error 0.000336 


1063 


033-43741s NIP: survivor 10.:150..10.3 offset 0.000185, cdist 96.00223 
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Lab 34: Configuring NTP Servers, Clients, and Authentication—Part | 
Practical Scenario 


NTP is a critical component to network management. Without a common clock, it is difficult to 
track and correlate any network anomalies. By having NTP configured, all the routers will be 
synchronized to the same clock, and troubleshooting the network will be much easier. 


Lab Exercise 


You are an engineer at management.com networks. You will be in charge of synchronizing all the 


routers in the network to one common clock source. Before rolling out NTP to the whole network, 
you will perform a proof-of-concept test with the following conditions: 


e At this time, you do not have access to an NTP server, and you must find a way for the 
router to provide NTP service to the network. 

e All routers are located in the United States- Pacific Time zone, which is an 8-hour offset 
from Greenwich Mean Time or UTC. Ensure that this is the time zone for the network, and 
use the name of PAC for a description. 

e Make NTP pass secure updates. 

e The remote router, client_router, should have a stratum of 6 when its clock is 
synchronized to the mngt_router. 

e (Optional) Set up all the routers for daylight saving time. Use S-PAC for the description 
when in daylight saving time. 


Lab Objectives 


e Configure the network as depicted in Figure 17-7. Use OSPF as the routing protocol, and 
put the client router in a stub area. 


Figure 17-7. Management.Com Networks: NTP Proof-of-Concept 
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e Configure the management router as an NTP server and the client router as an NTP client. 
e Use MD5 authentication for NTP; use cns for the password with a key of 2. 
e Set the appropriate stratum level. 
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Equipment Needed 


e Two Cisco routers. The routers should be connected through V.35 back-to-back cables or 
in a similar manner. The routers must support NTP—a Cisco 2500 or greater series. To 
model this network, we used Cisco 4700 and Cisco 2500 series routers. 

e Two LAN segments, provided through hubs or switches. 


Physical Layout and Prestaging 


e Connect the hubs and serial cables to the routers, as shown in Figure 17-7. Use HDLC as 
the WAN protocol. 


e Connect the two Ethernet hubs to the routers to form two LAN segments, as shown in 
Figure 17-7. 
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Lab 34: Configuring NTP Servers, Clients, and Authentication— 
Part Il 


Lab Walkthrough 


After completing the physical installation of the LAN and WAN segments, you should establish 
IP connectivity among all the routers. Before trying to configure NTP, be sure to perform 
source pings from each router's Ethernet to verify end-to-end connectivity. 


Beginning with the mngt_router, configure the IP address of the Ethernet EO port and the 
serial port. This is not the DCE side of the serial link, so no clock rate command is needed. 
The WAN protocol is HDLC, so you do not need to configure an encapsulation type on this link. 


On the client_router, you need to configure an IP address on the EO port and the S1 port. 
Because this side is the DCE end, you need to add the clock rate command. 


Before moving on to OSPF, be sure that each router can ping the other router's serial port. 
The WAN is considered a local network, and the remote end should be reachable. 


To configure OSPF on the mngt_router, you need to add two network statements and an 
area subcommand. Example 17-20 lists the relevant IP configuration for the mngt_router as 


it stands at this point. 


Example 17-20 Relevant | P Configuration for the mngt_ router 


! hostname mngt_router 

! 

interface Ethernet0 

ip address 98.10.10.1 255.255.255.0 
media-type 10BaseT 

! 

interface Serial0 

ip address 98.10.128.1 255.255.255.252 
no ip mroute-cache 

! 
router ospf 100 

network 98.10.10.1 0.0.0.0 area 0 
network 98.10.128.1 0.0.0.0 area 100 
area 100 stub 


Configuring OSPF on the client_router is similar. Because the entire router exists in a stub 
area, you can simplify the config by using a wildcard mask on the network statement. Again, 
you also need the area stub command for Area 100. Example 17-21 lists the relevant IP 


configuration for the client_router. 


Example 17-21 Relevant | P Configuration for the client_ router 


hostname client_router 
! 


interface Ethernet0 
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ip address 98.10.16.1 255.255.255.0 

! 

interface Serial0O 

no ip address 

shutdown 

no fair-—queue 

! 

interface Seriall 

ip address 98.10.128.2 255.255.255.252 
clockrate 2000000 

! 
router ospf 100 

network 98.10.0.0 0.0.255.255 area 100 


area 100 stub 
1 


Moving on to the NTP portion of the config, you need to configure the following: 


NTP master with a stratum level of 5 on the mngt_router 

MD5 authentication with trusted key of 2 and a password of cns 

NTP client on the client_router so that its stratum is 6 when synced 

Time zone of PAC with an offset of -8 from UTC 

Optionally, daylight saving time across the network, with the name of S-PAC 


To configure the NTP on the mngt_router, you need to add the command ntp master 5. The 
5 sets the stratum to 6 on the client side when it synchronizes with the client_router. To 
enable authentication, follow this three-step process: 


Step 1. Enable authentication. 
Step 2. Define authentication keys. 
Step 3. Define trusted keys. 


Example 17-22 illustrates performing these commands on the master_router. The exact 
same authentication commands will be used on the client_router. 


Example 17-22 Configure NTP and MD5 Authentication on the 
mngt_ router 


mngt_router (config) #ntp master 5 

mngt_router (config) #ntp authenticate 

mngt_router (config) #ntp authentication-key 3 md5 cns 
mngt_router (config) #ntp trusted-key 3 

mngt_router (config) #exit 


Configuring the client router is similar to configuring the master, except that you use the ntp 
server 98.10.128.I command in place of the ntp master command. The authentication 
portions of the configuration will be identical to those of the mngt_router. 


Check the status of NTP synchronization by using the show ntp status and show ntp assoc 
commands. Performing these commands on the client_router generates the output listed in 
Example 17-23. 
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Example 17-23 show ntp status and show ntp assoc Command Output 


client_router#show ntp status 
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**19 


clock offset is -0.3234 msec, root delay is 4.46 msec 

root dispersion is 0.52 msec, peer dispersion is 0.15 msec 
client_router# 

client_router#show ntp assoc 


address ref clock st when poll reach delay offset disp 
#9810 .128:..1 12 DAT Fed 5 59 64 377 4.5 =0:..32 On 
* master (synced), # master (unsynced), + selected, - candidate, ~ configured 


client_router# 


Example 17-23 verifies that the clock is synchronized and that the stratum is set to 6. Also 


note that the clock has the appropriate reference, which should be the one that you 
configured. 


Finally, you need to set the time and clock in accordance with the time zone and name 
specified in the lab. To configure this, use the clock timezone PAC - 8 command on both 
the client and the host router. Now when you view the time, the UTC time should be replaced 
with PAC time and should be offset by 8 hours. 


The optional part of the lab consists of adding daylight saving time to the network. This is 
accomplished by using the clock summer-time S-PAC recurring command on both 
routers. If you are in daylight saving time, your router will now have output similar to 
Example 17-24. 


Example 17-24 show ntp status While in Daylight Saving Time 


client_router#show ntp status 
Clock is synchronized, stratum 6, reference is 98.10.128.1 
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**19 


clock offset is -0.5572 msec, root delay is 4.49 msec 


root dispersion is 0.66 msec, peer dispersion is 0.06 msec 
client_router# 


Example 17-25 shows the configurations for both routers. 


Example 17-25 Configurations for the mngt_router and the 
client_ router 


hostname client_router 
! 

enable password cisco 
! 

clock timezone PAC -8 


clock summer-time S-PAC recurring 
! 
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interface Ethernet0O 

ip address 98.10.16.1 255.255.255.0 

! 

<<<text omitted>>> 

! 

interface Seriall 

ip address 98.10.128.2 255.255.255.252 
clockrate 2000000 

' 

<<<text omitted>>> 

' 

router ospf 100 

network 98.10.0.0 0.0.255.255 area 100 
area 100 stub 

' 

ip classless 

! 

<<<text omitted>>> 


ntp authentication-key 2 md5 070C2F5F 7 
ntp authenticate 

ntp trusted-key 2 

ntp clock-period 17179866 

ntp server 98.10.128.1 


hostname mngt_router 

! 

enable password cisco 

! 

clock timezone PAC -8 

clock summer-time S-PAC recurring 

! 

! 

interface Ethernet0 

ip address 98.10.10.1 255.255.255.0 
media-type 10BaseT 

! 

<<<text omitted>>> 

! 

interface Serial0 

ip address 98.10.128.1 255.255.255.252 
no ip mroute-cache 

! 

<<<text omitted>>> 

! 

router ospf 100 

network 98.10.10.1 0.0.0.0 area 0 
network 98.10.128.1 0.0.0.0 area 100 
area 100 stub 

! 

ip classless 

! 

<<<text omitted>>> 

! 

ntp authentication-key 2 md5 104D070A 7 
ntp authenticate 

ntp trusted-key 2 

ntp master 5 
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Lab 35: Configuring NTP Servers, Clients, and Peer Associations— 
Part | 


Practical Scenario 


As mentioned previously, NTP is a critical component to network management and for applications 
that may require an accurate time source. Cisco routers can be configured to synchronize to an 
external time source and, in turn, have other routers synchronize to them. 


Lab Exercise 


Independent Ticket, Inc. runs a concert ticket sales application that requires an accurate clock to 
ensure that ticket sales start and stop at the correct times. This particular application is run by a 
small group of bands that want to coordinate their own ticket sales instead of relying on existing 
ticket monopolies. The bands all have 56-kbps links to a small central site that provides common 
venue information, as well as a secure NTP server. The bands Metallica and Pearl Jam have 
recently signed up for NTP services. You are tasked to configure the new metallica and pearl_jam 
routers with the following conditions: 


e The network will have a core router, ticket_central, with two 56-kbps HDLC links to the 
metallica and pearl_jam routers. 

e An NTP server resides on the backbone Ethernet segment of the ticket_central router. The 
NTP server has an IP address of 206.191.241.45. Configure the ticket_central router to 
synchronize to this server. 

e Configure the metallica and pearl_jam routers to form a peer association with the 
ticket_central router. 

e All routers are located in the United States- Pacific time zone, which is an 8-hour offset 
from Greenwich Mean time or UTC. Ensure that this is the time zone for the network, and 
use the name of PAC for a description. 

e (Optional) Prevent any NTP broadcast from being broadcast onto the Ethernet segments of 
the metallica and pearl_jam routers. 


Lab Objectives 


e Configure the network as depicted in Figure 17-8. Use EIGRP as the routing protocol, with 
an autonomous System ID of 2001. 


Figure 17-8. NTP Peer Association Configuration 
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e Configure the ticket_central router as an NTP master, and source its clock from 
206.191.241.45, the NTP server. 

e Configure the metallica and pearl_jam routers to form a peer association with the 
ticket_central router. 

e The stratum level should be 5 at the remote sites. 


Equipment Needed 


e Three Cisco routers. Two routers should be connected through V.35 back-to-back cables to 
the serial ports of the ticket_central router. 

e Three LAN segments, provided through hubs or switches. 

e An NTP server located on the Ethernet segment of the ticket_central router. Use the 
shareware site download.com to download an NTP server for the lab. The NTP server that 
we used is called TARDIS 2000 and is available at this site. Any NTP server or another 
router could also serve this function. 


Physical Layout and Prestaging 


e Connect the hubs and serial cables to the routers, as shown in Figure 17-8. Use HDLC as 
the WAN protocol. 

e Connect the three Ethernet hubs to the routers to form three LAN segments, as shown in 
Figure 17-8. 

e Configure EIGRP across the network, use 2001 as the Autonomous System ID. 

e Add and configure the NTP server on the Ethernet segment of the ticket_central router. 
Enable NTP broadcast, and set the stratum level to 3 on the software. The IP address of 
the server is 206.191.241.45. 
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Lab 35: Configuring NTP Servers, Clients, and Peer Associations—Part 
ll 


Lab Walkthrough 


After completing the physical installation of the LAN and WAN segments, you should establish IP 
connectivity among all the routers. Before trying to configure NTP, be sure to perform source pings 
from each router's Ethernet to verify end-to-end connectivity. 


Beginning with the ticket_central router, configure the IP address of the EO port and the two serial 
ports. This end is the DCE side of the serial link, so a clock rate command is needed; use the clock 
rate 56000 command on the SO and S3 interfaces. The WAN protocol is HDLC, so you will not need 
to configure an encapsulation type on this link. 


On the metallica and pearl_jam routers, you need to configure an IP address on the EO ports and the 
SO ports. When the IP addresses are configured and the links are brought up, you should be able to 
ping other routers' serial ports. 


When the interfaces are up, configure EIGRP on all the routers, and use the autonomous System ID 
of 2001. Example 17-26 lists the relevant IP configuration for the all the routers in the lab. 


Example 17-26 Relevant | P Configuration for the Routers in This Lab 


hostname ticket_central 
! 
interface Ethernet0O 
ip address 206.191.241.43 255.255.255.248 
! 
interface Serial0O 
ip address 172.10.128.1 255.255.255.252 
no fair-—queue 
clockrate 56000 
! 
<<<text omitted>>> 
! 
interface Serial3 
ip address 172.10.128.5 255.255.255.252 
clockrate 56000 
! 
<<<text omitted>>> 
! 
router eigrp 2001 
network 206.191.241.0 
network 172.10.0.0 


hostname pearl_jam 
! 
interface Ethernet0O 
ip address 172.10.33.1 255.255.255.0 
! 
interface Serial0O 
ip address 172.10.128.6 255.255.255.252 
no ip directed-broadcast 
no ip mroute-cache 
no fair-—queue 
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<<<text omitted>>> 
! 

router eigrp 2001 
network 172.10.0.0 


hostname metallica 
! 
interface Ethernet0O 
ip address 172.10.32.1 255.255.255.0 
! 
interface SerialO 
ip address 172.10.128.2 255.255.255.252 
no ip directed-broadcast 
no ip mroute-cache 
no fair-—queue 


<<<text omitted>>> 
! 
router eigrp 2001 


network 172.10.0.0 
\ 


To configure NTP on the ticket_central router, you must configure it as a both a client and a master. 
First, use the ntp server 206.191.241.45 command to point to the NTP server off its EO port. At 
this time, you can also configure this router as an NTP master. To accomplish this, use the ntp 
master command. There is no need to add a stratum because you want to preserve the stratum 
number that the NTP server broadcasts. The last step is to set the time zone to Pacific time, with an 
8-hour offset. This is done by using the clock timezone PAC - 8 command. Example 17-27 lists the 


NTP configuration of the ticket_central router. 


Example 17-27 NTP Configuration of ticket_ central 


ticket_central (config) #clock timezone PAC -8 
ticket_central(config)#ntp server 206.191.241.45 
ticket_central (config) #ntp master 


Check the status of NTP by using the show ntp status command. Look for the clock to be 
synchronized; it should have a reference clock of 206.191.241.45. 


Finally, you can configure the NTP peer associations on the metallica and pearl_jam routers. Use the 
ntp peer 172.10.128.1 and ntp peer 172.10.128.5 commands, respectively, on these routers. 
Use the same clock timezone PAC - 8 command to set the time zone to Pacific time. 


Use the show ntp status and show ntp associations commands on the remote routers to verify 
NTP synchronization. Example 17-28 lists the output of these commands on the metallica router. 


Example 17-28 Verifying NTP Synchronization 


metallica#show ntp status 


nominal freq is 250.0000 Hz, actual freq is 250.0010 Hz, precision is 2**19 
reference time is BD1D1551.469209A4 (21:17:05.275 PAC Sun Jul 16 2000) 
clock offset is -10.3164 msec, root delay is 34.47 msec 

root dispersion is 70.31 msec, peer dispersion is 3.92 msec 

metallica# 

metallica#show ntp associations 
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address ref clock st when poll reach delay offset disp 


* master (synced), # master (unsynced), + selected, - candidate, ~ configured 
metallica# 


Notice that the reference clock in the show ntp associations command is that of your original NTP 
server, 206.191.241.45. The stratum of 5 indicates that the stratum is being passed and 
incremented from the original NTP server. 


The optional part of this exercise consists of preventing NTP broadcasts on the Ethernet segments of 
the remote routers. To disable NTP broadcasts of any interface on a router, use the ntp disable 
command under the interface that you want to disable the broadcast from entering. Example 17-29 


lists the configurations of the metallica and pearl_jam routers. 


Example 17-29 Configurations of the metallica and pearl_jam Routers 


hostname metallica 

! 

clock timezone PAC -8 

! 

interface Ethernet0 

ip address 172.10.32.1 255.255.255.0 
ntp disable 

! 

interface Serial0 

ip address 172.10.128.2 255.255.255.252 
no ip directed-—broadcast 

no ip mroute-cache 

no fair-—queue 


<<<text omitted>>> 
! 
router eigrp 2001 
network 172.10.0.0 
! 
<<<text omitted>>> 
! 
ntp clock-period 17179749 
ntp peer 172.10.128.1 


hostname pearl_jam 

! 

! 

clock timezone PAC -8 

! 

interface Ethernet0 

ip address 172.10.33.1 255.255.255.0 
ntp disable 

! 

interface Serial0 

ip address 172.10.128.6 255.255.255.252 
no fair-—queue 

! 

<<<text omitted>>> 

! 

router eigrp 2001 

network 172.10.0.0 

! 

<<<text omitted>>> 
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! 
ntp clock-period 17179636 
ntp peer 172.10.128.5 
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Part Vill: CCIE Preparation and Self-Assessment 


Chapter 18 The CCIE Practical Exam: Preparation and CCIE Practice Labs 
Part VIII CCIE Preparation and Self-Assessment 
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Chapter 18. The CCIE Practical Exam: Preparation and 
CCIE Practice Labs 


There are no shortcuts to success, and don't waste time looking them. 


These words come from one of my personal heroes, retired General Colin Powell. His words of 
advice ring true for soldiers as well as anyone striving to become a CCIE. There exists no 
single source of CCIE knowledge, no all-in-one book, including this text, that will get you into 
the ranks of the CCIEs. And as Powell's words echo, "don't waste time looking for them." At 
the time of this writing, September 2001, Cisco states that there are 6678 active CCIEs in the 
world. When you compare this number to how Cisco predominates the market, the ranks of 
the CCIEs still remain very slim. 


The CCIE program is constantly changing to reflect current market trends. In 1997, all the 
tests were made standard. In 1999, Cisco offered more then the core "routing and switching" 
exam. You could specialize in WAN switching, or SNA and others. These specialization 
certifications also have changed in recent years. In 2000, voice and ATM where introduced, 
whereas years before that, switches were emerging in the lab. In 2001, the test moved from 
a two-day, 16-hour test to a one-day, 8 1/2-hour test. With all the changes the CCIE 
practical/lab has gone through, one thing does remain the same: Over time, it constantly 
gets harder. For instance, when | became a CCIE, | did not have to know voice, Token Ring 
switching, or ATM. This is precisely why there is no single source for CCIE information: The 
test is and will be ever-changing. 


The best place to find the most current information about the CCIE program is on the Web at 
www.cisco.com/go/ccie. 
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The New One-Day CCIE Lab Exam 


| was fortunate enough to talk to Lorne Braddock Sr., the manager of the CCIE program, 
about the move from a two-day test to a one-day test. Like many CCIEs, | had a knee-jerk 
reaction to the move. | was aware of the huge backload that Cisco was experiencing with 
people waiting to get into the lab; in some cases, the waiting list was approaching a year 
long. Many Cisco partners required people to get certified to retain or gain a preferred 
partner status. For many Cisco partners, the revenue difference between a gold and silver 
partnership is in the millions. Another problem for Cisco and its customers was the difficulty 
in scheduling a two-day exam that you can get sent home early on. This not only costs time 
and money to Cisco's customers, but it also leaves many open lab slots. 


Moving to a one-day, 8 1/2-hour test resolved many of these problems, but the question 
remained—what do you cut? The program decided to enhance the Layer 1 or physical aspect 
of the written test. The physical portion of the lab exam was a rather "technically" small 
portion of the lab exam, but it did consume some time. Another portion of the exam that 
could be cut was the troubleshooting portion. The reality is that if you spent the last 8 1/2- 
hours successfully configuring this very difficult exam, you are not going to get stumped 
when someone changes the router password or an IP address. | personally know a lot of 
CCIEs, and of those who have failed the exam, no one has ever failed the troubleshooting 
portion. Therefore, the four hours of troubleshooting also was cut from the lab exam. 


In a nutshell, Cisco made the written portion of the CCIE exam more difficult because it deals 
with more physical layer topics. The lab exam now is a one-day, 8 1/2-hour exam in which 
time will be critical factor. 
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How Do | Become a CCIE? 


The first step with any serious undertaking is to take a hard, honest assessment of your 
current skills. Know your strengths and acknowledge your weaknesses. Cisco has specifically 
designed the CCIE practical exam to weed out candidates with little "hands-on" or "field" 
experience. When you take your personal assessment, be very honest with past experience. 
This will help you identify the areas that you need to focus on. For instance, many people 
(unless they have worked with SNA) have little field experience in DLSw. Modeling DLSw in 
the lab will give you the valuable experience that you need for the practical exam. 


The second step is to dedicate and commit yourself to passing the exam. Plan to commit 
yourself to one to three years of intense training to become certified. You must be willing to 
read a lot of books and spend months in the lab. You must take your current understanding 
of topologies and protocols to the next level. You won't be "memorizing" how Spanning Tree 
works, but you will be "understanding" how and why it needs to work. Anything short of very 
serious preparation will leave you short when test day arrives. 


Perhaps the most critical part of your studies will be the last two to three months. By this 
time, you should have all of your "formal" or "classroom" education out of the way, and you 
should be applying it in the lab. You should have read most of your books, and you will be 
focusing on the advanced elements of the technologies that you are working with. During the 
last two months, spend as much time in the lab configuring as many different network 
scenarios as you can think of. Read through all the configuration guides and browse the CD. 
Make yourself aware of the ways to tune each protocol or feature set. This also will help you 
become familiar with the configuration guides and CD; they will be your only source of 
information during the lab exam. You will have this information available; however, the new 
test is very time-intensive. If you have to look up commands and study manuals, chances are 
good that you will run out of time during the practical exam. 


Finally, if you do come up short on test day, don't give up. Yes, people have passed the lab 
on the first try, but a majority of us had to come back on another day. Hang in there, and, 
remember, "Nothing worthwhile ever comes easy." 


Good luck. 
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CCIE: Recommended Study Resources and Topics Outline 


This book serves as only one of many that you will have to read during your studies. The 
following books are a brief list of the ones that will be of great value during your studies; 
another list is provided on the CCIE page, mentioned previously: 


Stevens: TCP/IP Illustrated 
Comer: Internetworking with TCP/IP 


Perlman: Interconnections, Second Edition: Bridges, Routers, Switches, and 
Internetworking Protocols 


Doyle: Routing TCP/IP, Volume | and II 

Halabi: Internetwork Routing Architectures 
Hamilton/Clark: Cisco LAN Switching 

Caslow, Bruce: Bridges, Routers, and Switches 
Cisco Press: CCIE Network Design and Case Studies 
Diker-Pildush: Cisco ATM Solutions 


Table 18-1 provides a rough outline (but by no means a complete list) of CCIE study topics. 


It offers a solid starting point for a list of topics that the CCIE candidate should become very 
familiar with. 


Table 18-1. CCIE Study Topic Outline 


| Main Topic | Subtopics 


Frame Relay Frame Relay switching 


Frame Relay subinterfaces 


Point-to- point links and multipoint links 


Frame Relay map statements: bridge, LLC, 
DLSw and other keywords 


RFC 1490 encapsulation 


Bridging over Frame 
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Voice over Frame 
PPP over Frame 


Frame Relay ARP and Inverse ARP 
operation 


Frame Relay traffic shaping 


HDLC [Compression types 


PPP PPP authentication: PAP/CHAP 
PPP callback 
PPP multilink 
DDR techniques 
Compression types 


PCP 


ISDN Dialer maps/DDR 


Running every protocol over ISDN: IPX, IP, 
and so on 


How to handle routing protocols over ISDN, 
such as EIGRP, OSPF, |GRP, and others 


Snapshot routing 
Dialer watch 
Demand circuits 


Complex IPX and IP ACLs to control dialing 
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BGP Route reflectors 


Use of loopbacks 


Synchronization rule 


IBGP versus EBGP 


Route maps and route redistribution 


AS path filters 


BGP path selection process and path 
manipulation: MED, local preference, weight, 
and so on 


BGP confederations 


BGP communities 


Advertising supernets, summarization 


BGP maps 


Redistribution to and from every routing 
protocol 


Summarization with summary address and 
area range statements 


OSPF over Frame and X.25 


OSPF demand circuits 


Route maps and route filters with OSPF 


OSPF costs and administrative distance 


Stub areas, NSS areas, and backbone areas 


Authentication: Type | and Type II 


Designated router and BDR selection: priority 
command 


Default route propagation 
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EI GRP EIGRP for IP and IPX 


Redistribution to and from every routing 
protocol 


Summarization 


Route maps and route filters with EIGRP 


MD5 authentication 


EIGRP over ISDN 


Split-horizon issues with multipoint networks 


Administrative distance 


Redistribution to and from every routing 
protocol 


Snapshot routing/IGRP over ISDN 


Split-horizon issues with multipoint networks 


Default networks 


Administrative distance 


Issues from lack of VLSM support 


Redistribution to and from every routing 
protocol 


Snapshot routing/RIP over ISDN 


Split-horizon issues with multipoint networks 


RIP Version 1, issues from lack of VLSM 
support 


RIP Version 2 


1085 


IPX 


DLSw 


IPX routing protocols: NLSP/RIP/EIGRP 


Static SAPs, SAP filtering and propagation 


Network filtering 


Redistribution between NLSP, RIP, and EIGRP 


ACLs to control IPX dialing over ISDN 


Snapshot routing/IPX over ISDN 


Tunneling | PX 


Split-horizon issues with multipoint networks 


SPX and watchdog spoof 


IPX frame types, such as type 20 frames 


TCP, FST, direct, and Frame Relay peers 


Backup peers 


Promiscuous peers 


Border peers and peer groups 


Costed peers 


Explorer control and LLC control with DLSw 
LSAP filters 


Transparent bridging 


Spanning Tree control 


Bridging over Frame Relay 


Source-route bridging 


Remote source-route bridging 


Translational bridging 


Explorer control and flooding 
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LSAP filters 


Integrated routing and bridging 


Default gateways 


Standard access lists 


Controlling routing and traffic 


Extended access lists 


Named access lists 


Dynamic and reflective access lists 


Route maps and policy routing 


Propagating default routes 


Weighted fair queuing 


Priority queuing 


Custom queuing 


Generic and Frame Relay traffic shaping 


RSVP, WRED basic configurations 


General Cisco |OS Software Access server configuration 


topics 


Jump register configuration 


Password recovery for Catalyst switches and 
routers 


Configuration through TFTP and autoinstall 


Exec control: timeouts, privilege levels, and so 
on 


Security 


Logging 
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Cisco |1OS Software features NAT: Dynamic, static, and pooled 


NTP: NTP authentication and stratum settings 


DNS 


HSRP: tracking and priority 


IRDP 


Snapshot routing 


Dialer watch 


Mobile IP 


ARP manipulation 


SNMP: read/write keys, set and get traps 


UDP flooding: |P Forward command 


GRE tunneling 


Catalyst switches Cat 55xx VLAN creation 


Cat 39xx VLAN creation 


Cat 29xx VLAN creation 


VTP domains 


Spanning Tree control 


Port security and IP access control 


ISL, 802.1Q trunking 


VLAN propagation and control over trunks 


Routing between VLANs 


Multicast routing 
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Multicast routing Joining multicast groups 


Sparse- and dense-mode operation 


Classical IP, routing over ATM 


VPI, VCD, and VCI definition 


ARP control 


PVC mapping 


Voice over IP 


Voice over Frame 


Voice over ATM 


FXO and FXS and E&M circuits 


H.323 


Encryption types 


|PSec- protected BGR tunnels 
IPSec transport and tunnel mode 
Transform sets, crypto maps 


"Key" authentication 


Removed topics (removed in 2) 


Banyan VINES 


ISO CLNS 
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XNS 


M2 


The practice labs are designed to give you an accurate representation of what a CCIE Lab 
Exam actually looks like. Many topics on the practice labs are not covered in this volume. As 
mentioned previously, one book—not even one this size—can possibly cover all the topics on 
the CCIE exam, at least in any depth. Topics such as BGP, IPX, multicast, and IPSec will be 
covered in CCIE Practical Studies, Volume II. 


The labs are divided into two parts and are timed labs. Each lab has different hardware 
requirements and might require some prestaging to make the labs operate properly. As with 
the real lab, the answers are not provided. The solutions are posted on Cisco Press Web site 
at www.ciscopress.com/1587200023. We are doing this to encourage you to actually practice 
the labs and to exhaust all possible means of designing a solution before having to look at 
the answers. You should allow yourself 8 1/2 hours to complete each lab. 
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CCIE Practice Lab: "Skynet" 


1091 


Equipment List 


One Frame Relay switch: four serial ports 

One access server/backbone router: eight asynchronous interfaces, one Ethernet port 
Two lab routers: one Ethernet, two serial interfaces 

Three lab routers: one Token Ring, two serial interfaces 

One lab router: two Ethernet ports, one Token Ring port 

Three Ethernet hubs, four Token Ring hubs/MAUs 

The hubs and MAUs may be substituted for a Catalyst 5000 with the appropriate 
number of ports. This lab is designed to be performed without any Catalyst switches. 
It is the only lab that does not require a switch. 
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Prestaging: Frame Switch Configuration 


Configure the Frame Relay switch with the PVCs as depicted in Figure 18-1; do not time 
yourself on this portion of the lab. Example 18-1 lists the configuration for the Frame Relay 
switch. 


Figure 18-1. Frame Relay Switch Configuration 
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Example 18-1 Frame Relay Switch Configuration 


hostname frame_switch 

! 

frame-relay switching 

! 

<<<text omitted>>> 

! 

interface Serial0 

no ip address 
encapsulation frame-relay 
no fair-—queue 
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clockrate 148000 

frame-relay lmi-type ansi 

frame-relay intf-type dce 

frame-relay route 121 interface Seriall 120 
frame-relay route 152 interface Serial5 151 
! 

interface Seriall 

no ip address 

encapsulation frame-relay 

clockrate 148000 

frame-relay lmi-type ansi 

frame-relay intf-type dce 

frame-relay route 110 interface Serial5 111 
frame-relay route 120 interface SerialO 121 
frame-relay route 130 interface Serial3 131 
! 
interface Serial3 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay lmi-type ansi 

frame-relay intf-type dce 

frame-relay route 131 interface Seriall 130 
! 
interface Serial5 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay lmi-type ansi 

frame-relay intf-type dce 

frame-relay route 111 interface Seriall 110 
frame-relay route 151 interface SerialO 152 
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Prestaging: Backbone Router Configuration 


Configure R7 as a backbone router. Configure R7 as an external BGP peer to R2's IP address 
of 192.128.128.2/24. Use 2010 as the Autonomous System ID for this router. Configure 
loopback interfaces on this router with the following addresses: 


128.200.1.1/24 
128.201.1.1/24 
128.202.1.1/24 


Use the network command to circulate the networks. Example 18-2 illustrates the 
configuration of the backbone router R7. 


Example 18-2 Backbone Router Configuration 


hostname r7_backbone_router 
! 
interface Loopback20 
ip address 128.200.1.1 255.255.255.0 
! 
interface Loopback21 
ip address 128.201.1.1 255.255.255.0 
! 
interface Loopback22 
ip address 128.202.1.1 255.255.255.0 
! 
interface Ethernetl 
description place in vlan 3 —- backbone 1 
ip address 192.128.128.1 255.255.255.0 
media-type 10BaseT 
ip rip send version 2 
ip rip receive version 2 
! 
router rip 
version 2 
no auto-summary 
network 192.128.128.0 
network 128.200.0.0 
network 128.201.0.0 
network 128.202.0.0 
! 
router bgp 2010 
no synchronization 
network 192.128.128.0 
network 128.200.0.0 
network 128.201.0.0 
network 128.202.0.0 
neighbor 192.128.128.2 remote-as 2001 
neighbor 192.128.128.2 ebgp-multihop 10 
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The following portion of the lab is timed, and it should begin after the configuration and 
physical installation of the Frame Relay switch and the backbone router. 
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Timed Portion 


Lab Rules 


No static routes or floating static routes are used unless specifically stated. 

e Follow the instructions exactly. Be careful to propagate routes only where and when instructed. Use the 
PVCs only as directed by the instructions. 

e Primary configurations might need to be modified for Part Il only when you are finished with the primary 

configurations. 

You can use the configuration guides and the Cisco Documentation CD-ROM for your only reference 

material. 

You have 8 1/2 hours to complete the lab. Do not talk to anyone during this phase. 

It is recommended that you read the entire lab before beginning. 

Make an accurate and precise network illustration. 

Use Figure 18-2 as a reference for the physical layout of the lab. 


Figure 18-2. Network Diagram for "Skynet" 
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1. Access server: Configure the access server/router so that all the routers and the switches can be 
accessed through reverse Telnet. Password-protect all routers and switches with the password cisco. 


2. IP address assignment: Assign an IP addresses to all physical interfaces as denoted in Figure 18-2. Use 
the major network of 140.100.x.x on all interfaces. Use a 24-bit mask on all interfaces except for the 
following: 


R1: Allow for 30 host addresses on the Token Ring interface. Use a 30-bit address on the 
PPP and Frame link between R1 and R4. 


R2: Use an IP address of 192.128.128.2/24 on the Ethernet interface. Assign a 30-bit 
subnet to the HDLC link between R2/R5. 


R3: Configure the IPX network DEAD on a loopback interface. 


R4: Use a 27-bit mask on the Token Ring interface. Configure 18-10 loopback interfaces; 
use the IP addresses of 199.199.1.1/24 to 199.199.10.1/24. 


Figure 18-10. Network Diagram for "The Unnamed lab" 
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R5: Configure the Token Ring to support 14 hosts. Configure three loopback addresses, 
with the IP addresses of 151.100.1.1/24, 151.101.1.1/24, and 172.16.1.1/24. Assign #098 


bit subnet to the HDLC link between R2/R5. 


R6: Assign the IP address of 10.10.10.1/24 to the Ethernet interface on VLAN 2. Full IP 
and IPX connectivity to all Ethernet, Token Ring, and loopback interfaces will be expected 
unless noted. 


3. Document the network thoroughly; include all OSPF areas, IP/IPX address, |PX networks, and so on. 


Section II: Catalyst/LAN Configuration 


1. Configure the VLANs as depicted in Figure 18-2. Configure the Token Ring segments, and connect R2 to 
the backbone routers Ethernet segment. 


Section Ill: OSPF and Frame Relay Configuration 


1. Configure the Frame Relay network as shown in Figure 18-2. You may use subinterfaces only on R1. Use 
only the DLCls shown in the diagram to route traffic. Traffic from R2 to R3 should all go through R1. 


2. R1, R2, and R3 should share the same IP subnet. Configure OSPF Area 0 between the routers; do not use 
the ip ospf network command when configuring OSPF. Configure the Frame link between R1 and R4 to 
also be in OSPF Area 0. 


3. Configure the PPP link between R1 and R4 to be in OSPF Area 10. Ring 2 is in OSPF Area 20. This link 
should become active only upon a loss of Frame service. 


4. Change the OSPF hello time on the serial link of R3 so that hellos are broadcast every 60 seconds. 


5. Advertise the 10 loopback addresses on R4, 199.199.1.1 to 199.199.10.1, through OSPF without 
assigning an area to them. 


Section IV: Routing Protocols and Redistribution 


1. Configure IGRP on VLAN 1 on R3/R6, and Ring 3 on R6 only. Do not allow IGRP broadcast onto VLAN 2. 


2. Configure RIP 2 on R2 going to the backbone router. Configure R2 to send and receive only version II 
updates to and from the backbone router. 


3. Prevent the subnet of the Token Ring network on R4 from reaching R7. 


4. Configure EIGRP on the HDLC link between R2/R5. Configure EIGRP on Ring 4 of R5. Use 2020 as the 
Autonomous System ID. 


5. Summarize the loopback networks of 151.100.1.1 and 151.101.1.1 into one advertisement. Ensure that 
R6 can ping all EIGRP networks, without adding a static route. 


Section V: IPX Configuration 
1. Configure IPX NLSP on R5's Ring 4 and on R2. 
2. Configure |PX RIP/SAP on all LAN interfaces only. 
3. Configure |PX EIGRP on the Frame Relay WAN links. 


4. Apply a static SAP to R6 that is three hops away out its Token Ring interface. The SAP offers print 
services and should be configured as such. 


5. Prevent R3 from propagating this SAP across the WAN. 
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6. R3 should have a loopback interface configured with the IPX network DEAD; prevent only R4 from 
receiving this route. 


Section VI: Bridging 
1. Transparently bridge SNA from VLAN 1 to VLAN 3/Backbone 1, across the Frame Relay network. 
2. Force the selection of ROOT bridge to go to R1. 


Section VII: MISC IOS Configuration 


1. Configure CHAP authentication on the PPP link between R1 and R4. Use ccie as the password. 


2. Apply an inbound filter to R5, filtering just the even subnets from the loopback range 199.199.1.1 to 
199.199.10.1 on R4. 


3. Apply an inbound traffic filter to R6 so that only routing protocols, pings, and WWW can enter the router 
and have access to the WWW hosts on Ring 3 and VLAN 2. 


4. The user skynet resides on R1. Allow this user access to all IP services on Ring 3 and VLAN 2. This access 
should be valid for only 10 minutes. 
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Part Il 
Section Vill: BGP Configuration 


1. Rl, R2, and R3 are in autonomous system 2001. R5 is in autonomous system 65001. 
Configure an EBGP peer from R2 to 192.128.128.1, which is in autonomous system 
2010. Configure an EBGP peer from R5 to R2. 


2. Configure IBGP from R2 to R1 and R1 to R3; do not configure a peer R2 to R3. Ensure 
that all BGP routers are receiving the routes 128.20x.1.0 from the backbone router. 


3. Have R2 advertise the supernet of 128.200.0.0 into the rest of the lab network, R1, 
R2, R3, R4, R6, R7; suppress all other subnets of 128.200.0.0. 


4. Have R5 advertise the 172.16.1.0/24 subnet via BGP. Advertise the routes with a 
metric of 75. 


5. When the backbone router receives the 172.16.1.0 route, it should appear to come 
from AS 2011. 


6. Change the BGP hello timer on R5 to be 5 minutes. 
Section IX: DLSw Configuration 

1. Configure a DLSw TCP peer between Ring 2 and Ring 3. 

2. Configure a DLSw FST peer between Ring 1 and Ring 4. 


3. Configure an additional peer between R1 and R4 so that full NetBIOS reachability will 
occur from Ring 3 to Ring 4, while minimizing explorer traffic. 


4. Configure a TCP peer from Ring 2 to Ring 1; allow this peer to always stay up and 
active, even upon a loss of Frame Relay service. 


5. Configure the peer of R5 to forward only frames destined toward the MAC address 
3745.0001.0101. 


Section X: Miscellaneous Cisco IOS Software Features 


1. The 10's network on VLAN 2 of R6 should not be advertised by a routing protocol. 
Configure the users of this VLAN so that they can reach the entire network, without 
changing the IP address or advertising the subnet 10.10.10.0. 


2. Configure multicast routing on R1, R3, and R6. R6 will join the multicast group of 
224.10.10.10. R6 should respond to pings from R3 and Rl. 
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CCIE Practice Lab: "Darth Reid" 


1102 


Equipment List 


One Frame switch: four serial ports 

One access server: eight asynchronous interfaces, one Ethernet port 
One backbone router: two Ethernet ports 

Two lab routers: one Ethernet, one ISDN, one serial interface 

Two lab routers: one Ethernet, one Token Ring, one serial interface 
Catalyst 5000 switch 

Catalyst 3900 switch 
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Prestaging: Frame Switch Configuration 


Configure the Frame Relay switch with the PVCs as depicted in Figure 18-3; do not time 
yourself on this portion of the lab. Example 18-3 lists the configuration for the Frame Relay 
switch. 


Figure 18-3. Frame Relay Switch Configuration 
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Example 18-3 Frame Relay Switch Configuration 


hostname frame_switch 

! 

frame-relay switching 

! 

<<<text omitted>>> 

! 

interface Serial0 

no ip address 
encapsulation frame-relay 
no fair-queue 
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clockrate 148000 

frame-relay lmi-type cisco 

frame-relay intf-type dce 

frame-relay route 121 interface Seriall 120 
frame-relay route 152 interface Serial5 151 
! 

interface Seriall 

no ip address 

encapsulation frame-relay 

clockrate 148000 

frame-relay lmi-type cisco 

frame-relay intf-type dce 

frame-relay route 110 interface Serial5 111 
frame-relay route 120 interface Serial0O 121 
frame-relay route 130 interface Serial3 131 
! 
interface Serial3 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay lmi-type ansi 

frame-relay intf-type dce 

frame-relay route 131 interface Seriall 130 
! 
interface Serial5 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay intf-type dce 

frame-relay route 111 interface Seriall 110 
frame-relay route 151 interface SerialO 152 


1105 


Prestaging: Backbone Router Configuration 


Configure R6 as a backbone router. Configure R6 as an external BGP peer to R1's IP address 
of 160.100.2.1 and R7's IP address of 160.100.1.1. Use 2001 as the Autonomous System ID 
for this router. Configure loopback interfaces on this router with the following addresses: 


160.100.100.1/24 
197.192.100.1/24 
197.192.101.1/24 
197.192.102.1/24 


Use the network command to circulate the networks. Example 18-4 illustrates the 
configuration of the backbone router R6. 


Example 18-4 Backbone Router Configuration 


hostname r6_backbone_router 
! 
interface Loopback20 
ip address 192.190.100.1 255.255.255.0 
! 
interface Loopback21 
ip address 192.190.101.1 255.255.255.0 
! 
interface Loopback22 
ip address 192.190.102.1 255.255.255.0 
! 
interface Loopback23 
ip address 160.100.100.1 255.255.255.0 
! 
interface Loopback24 
ip address 160.100.128.1 255.255.255.0 
! 
interface Loopback25 
ip address 160.100.129.1 255.255.255.0 
! 
interface Loopback26 
ip address 160.100.130.1 255.255.255.0 
! 
interface Ethernetl 
description place on vlan 20 - Backbone 1 
ip address 160.100.2.254 255.255.255.0 
media-type 10BaseT 
! 
interface Ethernet2 
description place on vlan 10 - Backbone 2 
ip address 160.100.1.254 255.255.255.0 


media-type 10BaseT 
! 
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router rip 
passive-interface Ethernet1 
network 160.100.0.0 

network 192.190.100.0 
network 192.190.101. 


network 192.190.102.0 
! 


oO 


router bgp 2001 

no synchronization 
network 160.100.100 
network 160.100.128 
network 160.100.129 mask 255.255.255.0 
network 160.100.130 mask 255.255.255.0 
neighbor 160.100.1.1 remote-as 2010 
neighbor 160.100.1.1 ebgp-multihop 10 
neighbor 160.100.2.1 remote-as 2010 
neighbor 160.100.2.1 ebgp-multihop 10 

! 

ip route 133.10.0.0 255.255.0.0 160.100.2.1 


mask 255.255.255.0 


.0 
-0O mask 255.255.255.0 
.0 
.0 


The following portion of the lab is timed and should begin after the configuration and physical 
installation of the Frame Relay switch and the backbone router. Do not configure any other 
routers at this time. 
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Timed Portion 
Lab Rules 


e No static routes or floating static routes are used unless specifically stated. 

e Follow the instructions exactly. Be careful to propagate routes only where and when 
instructed. Use the PVCs only as directed by the instructions. 

e Primary configurations might need to be modified for Part || only when you are finished 

with the primary configurations. 

You can use the configuration guides and the Cisco Documentation CD-ROM for your only 

reference material. 

You have 8 1/2 hours to complete the lab. Do not talk to anyone during this phase. 

It is recommended that you read the entire lab before beginning. 

Make an accurate and precise network illustration. 

Use Figure 18-4 as reference for the physical layout of the lab. 


Figure 18-4. Network Diagram for "Darth Reid" 
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Section I: Basic IP Configuration 


1. Access server: Configure the access server/router so that all the routers and the pyyiches 


can be accessed through reverse Telnet. Password-protect all routers and switches with 
the password cisco. 


. IP address assignment: Assign an IP addresses to all physical interfaces, as denoted in 
Figure 18-6. Use the major network of 133.10.x.x on all interfaces. Use a 24-bit mask on 


all interfaces except for the following: 


Figure 18-6. Network Diagram for "The Lab, the Bad, the Ugly" 
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R2: Use an IP address of 160.100.2.1/24 on the Ethernet interface; make this VLAN 20. 


R4: Use a 28-bit mask on the loopback interface, and use a 26-bit mask on the Ethernet 
interface. 


R1: Allow for 30 hosts on the loopback interface. Add an additional loopback with the 
address of 128.200.1.1/24. 


R3: Use a 25-bit mask on the loopback interface. Use an IP address of 160.100.1.1/24 on 
the Ethernet interface; make this VLAN 10. 


R5: Use a 26-bit mask on the Ethernet interface. 
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3. Full IP and I1PX connectivity to all Ethernet, Token Ring, and loopback interfaces will be 
expected unless noted. 


4. Document the network thoroughly; include all OSPF areas, |P/IPX address, IPX networks, 
and so on. 


Section Il: Catalyst Configuration 


1. Connect the R1, R4, and R5 routers to the Catalyst 5000. Connect the two Token Ring 
routers to the Catalyst 3900 Token Ring switch. 


2. Configure the Backbone 1 segment and Backbone 2 segment to be in separate VLANs of 
your choice. 


3. Configure R1 Ethernet as VLAN 2 on the Catalyst 5K. Configure the R4/R5 Ethernet 
segment as VLAN 1 on the Catalyst 5K. Assign an IP address in VLAN 2 IP range. 


4. Configure the Catalyst so that only users on VLAN 1 can access the switch through Telnet. 
Do not use an access list on any routers to control access to the Catalyst 5K. 


5. Configure the switch so that all VLAN 2 traffic can be monitored with a sniffer/ analyzer on 
port 2/10. 


6. Configure the MAXAGE of VLAN 2 Spanning Tree 25 seconds. 


7. Configure VLAN 2 so that the only device that can be used on its port is R1. If R1 is 
unplugged and another device is plugged into that port, the catalyst should deactivate the 
port. 


8. Configure the Token Ring switch so that it can be managed and configured through Telnet. 
Section Ill: OSPF and Frame Relay Configuration 


1. Configure the Frame Relay network as shown in Figure 18-4. You may use subinterfaces 
only on R1. Use only the PVCs shown in the diagram to route traffic. Traffic from R2 to R3 
should all go through R1. 


2. R1, R3, and R4 should share the same IP subnet. Configure OSPF Area 0 between the 
routers; do not change the ip ospf network type when configuring OSPF. 


3. Configure R4/R5 Ethernet to be in OSPF Area 30. Configure the R4's Token Ring to be in 
Area 30. Add a loopback interface on R5 with an IP address of 192.168.1.1/24. Put this 
address in OSPF Area 50. Prevent the R3 from seeing this route, but ensure that all other 
routers can. 


4. Configure Frame Relay traffic shaping on the PVC between R1 and R2 so that it responds 
to BECNs. The CIR provided by the carrier is 32 K. The local port speed on R2 is 64 K, 
while the local port speed of R1 is 1.54 Mb. 


Section IV: ISDN Configuration 
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1. Configure the ISDN interfaces, between R1 and R5, as a part of the OSPF backbone. 
Configure the router so that only R5 places a call. Be sure that you can ping the local ISDN 
interfaces before moving on. 


2. Configure R5 to place a call only when it detects a topology change in OSPF and if traffic is 
destined for opposite router. Routes should be passed between R1 and R5. 


Section V: Routing Protocols and Redistribution 


1. Configure IGRP on the Frame Relay link between R1 and R2. R2's Token Ring and R1's 
Ethernet also should be in the |GRP domain. Ensure that all OSPF routes can be seen by 
R2. Ensure that R2 can issue a source ping to all configured addresses. 


2. Configure EIGRP between R1, VLAN 2 and R4 Ring 1 and provide connectivity via El GRP. 


3. Configure RIP on R3's Ethernet port connecting to Backbone 1; use 160.100.1.1/24 for the 
IP address. Ensure that OSPF is not running on this interface. Redistribute RIP into OSPF. 
R3 should be capable of pinging R2's Token Ring. 


4. When RIP is configured properly, you should see routes through RIP on R3. Filter the 
routes so that only 192.190.102.0/24 will be redistributed into the lab. Do not allow any 
routes from the lab network to be advertised onto Backbone 1. 


5. Add an additional loopback address to R4; use 161.100.1.1/24 as the IP address. Place the 
loopback into the EIGRP domain. Summarize EIGRP so that the lab network has only one 
route for both 160.100.1.0 and 161.100.1.0. 


6. Configure the Ethernet interface of R2 on Backbone 1 with an IP address 160.100.2.1/24. 
Do not place the network into |GRP domain with the network command, but allow full 
connectivity to the entire network. 


Section VI: BGP 


1. Configure BGP on R2 and R3, using an Autonomous System ID of 2010. Configure two 
EBGP peers to 160.100.1.254 and 160.100.2.254 in AS 2001, yielding two exit points to 
your AS. Configure BGP on R1 and build an |BGP neighbor to R2 and R3. Ensure that R1 
contains multiple routes from AS 2001. 


2. Advertise the 128.200.1.0/24 route on R1 through BGP. 
3. Configure R2 and R3 so that all incoming BGP routes have a weight of 700. 


4. Configure all the routes going to AS 2001 so that AS 2001 will not advertise these routes 
to any other autonomous systems. 


5. Configure the routes coming from AS 2001 to be summarized into 1 route, and then 
redistribute it into OSPF. 


6. Ensure that you can ping all BGP routes, including 160.100.100.1, even if R2 or R3's 
Ethernet interface is down. 


Section VII: Miscellaneous Cisco IOS Software Configuration 
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1. On the Ethernet segment of R1, write a traffic filter blocking data from the following 
sources: (Use as few lines as possible.) 


Deny FTP, HTTP from 131.24.194.x 


Deny FTP, HTTP from 131.25.194.x 


Deny FTF, HTTP from 135.152.1.1 


Deny FTF, HTTP from 227.24.194.x 


Deny FTF, HTTP from 131.24.195.x 


Deny FTF, HTTP from 131.24.196.x 


2. Configure Rl, R4, and R5 as members of the multicast group 224.10.10.1. Configure R1 
and R4 to direct multicast traffic between the two VLANs. You can use any mode of 
multicast transport that you want. 


3. Configure HSRP between R4 and R5. Let R4 serve as the primary default gateway. If R4 
loses its frame interface, the default gateway should become R5's Ethernet interface. 
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Part II 


Section VIll: IPX Configuration 


1. Configure an IPX network on all interfaces except the loopback interfaces and the 
backbones. Use |PX EIGRP on the Frame Relay network, and use IPX RIP on all LAN 
interfaces. 


2. Configure a static SAP on R5. The SAP is file services SAP, called FILESERV, and it is 
two hops away on network OxBBOO. You can use a static route, if needed. 


3. Prevent R3 from seeing the SAP FILESERV. 


4. Configure |PX over ISDN on R1 and R5. Configure |PX so that routes are passed from 
R5 to R1 over ISDN. 


Section IX: DLSw Configuration 


1. Configure a DLSw TCP peer between VLAN 2 and Ring 2. Do not configure a remote 
peer on R2. 


2. Allow only SNA traffic to cross from VLAN 2 headed for Ring 2. Use as few lines as 
possible in the ACL. 


3. A large amount of IP fragmentation is occurring on VLAN 2. Tune DLSw so that the IP 
fragmentation will not occur as often. 


Section X: Bridging 


1. Configure remote source-route bridging from Ring 1 to Ring 2. One IBM mainframe 
resides on each Token Ring. Many retransmissions are occurring on the serial links 
between R2 and R4. This results in duplicate frames reaching the remote host at the 
same time as the first frame reaches the remote host. The duplication breaks LLC2, 
resulting in the loss of sessions between the two IBM mainframes. Prevent this from 
happing. Your solution should take into account scaling issues as well. 
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CCIE Practice Lab: "The Lab, the Bad, the Ugly" 
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Equipment List 


One Frame Relay switch: four serial ports 

One access server: eight asynchronous interfaces, one Ethernet port 

Two lab routers: one Ethernet, two serial interfaces, one ISDN BRI 

Two lab routers: one Token Ring, two serial interfaces 

One lab router: one Ethernet port, two serial interfaces 

Two Token Ring hubs/MAUs 

One Catalyst 5000 

If you have another Catalyst available, it will help simulate the trunk; however, it is 
not required. 
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Prestaging: Frame Switch Configuration 


Configure the Frame Relay switch with the PVCs as depicted in Figure 18-5; do not time 
yourself on this portion of the lab. Example 18-5 lists the configuration for the Frame Relay 
switch. 


Figure 18-5. Frame Relay Switch Configuration 


Frame Relay 
Configuration 


Four-port Frame Relay 
switch 


53-64 kbps oe 


OLCl=111 


DLGl=131 
DLGl=141 


DLCI=121 


Example 18-5 Frame Relay Switch Configuration 


hostname frame_switch 

! 

frame-relay switching 

! 

<<<text omitted>>> 

! 

interface Serial0 

no ip address 
encapsulation frame-relay 
no fair-queue 
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clockrate 148000 

frame-relay lmi-type ansi 

frame-relay intf-type dce 

frame-relay route 121 interface Seriall 120 
frame-relay route 152 interface Serial5 151 
! 

interface Seriall 

no ip address 

encapsulation frame-relay 

clockrate 148000 

frame-relay lmi-type ansi 

frame-relay intf-type dce 

frame-relay route 110 interface Serial5 111 
frame-relay route 120 interface SerialO 121 
frame-relay route 130 interface Serial3 131 
frame-relay route 140 interface Serial3 141 
! 
interface Serial3 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay lmi-type ansi 

frame-relay intf-type dce 

frame-relay route 131 interface Seriall 130 
frame-relay route 141 interface Seriall 140 
! 
interface Serial5 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay lmi-type ansi 

frame-relay intf-type dce 

frame-relay route 111 interface Seriall 110 


frame-relay route 151 interface Serial0O 152 


The following portion of the lab is timed, and it should begin after the configuration and 
physical installation of the Frame switch and the backbone router. Do not configure any other 
routers at this time. 
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Timed Portion 


Lab Rules 


No static routes or floating static routes are used unless specifically stated. 

Follow the instructions exactly. Be careful to propagate routes only where and when 
instructed. Use the PVCs only as directed by the instructions. 

Primary configurations might need to be modified for Part Il only when you are 
finished with the primary configurations. 

You can use the configuration guides and the Cisco Documentation CD-ROM for your 
only reference material. 

You have 8 1/2 hours to complete the lab. Do not talk to anyone during this phase. 
It is recommended that you read the entire lab before beginning. 

Make an accurate and precise network illustration. 

Use Figure 18-6 as reference for the physical layout of the lab. 


Section I: Basic IP Configuration 


1. 


Access server: Configure the access server/router so that all the routers and the 
switches can be accessed through reverse Telnet. Password-protect all routers and 
switches with the password cisco. 


IP address assignment: Assign an IP addresses to all physical interfaces, as denoted 
in Figure 18-6. Use the major network of 165.10.x.x on all interfaces. Use a 24-bit 
mask on all interfaces except for the following: 


R1: Use a 30-bit address on the HDLC link between R1 and R2. 
R2: Assign an IP address of 172.16.1.1/24 to a loopback interface. 


R4: Assign the IP address of 165.10.10.1 to the Ethernet interface. 
Assign an IP address of 200.128.1.1/24 to a loopback interface. 


R8: Assign the IP address of 10.10.10.1/24 to the Token Ring interface. 


Full |P and |PX connectivity to all Ethernet, Token Ring, and loopback interfaces will 
be expected unless noted. 


Document the network thoroughly; include all OSPF areas, |P/IPX address, IPX 
networks, and so forth. 


Section Il: Catalyst/LAN Configuration 


Configure the VLANs as depicted in Figure 18-6. R1, R3, and R6 reside on VLAN 1, 
while VLAN 2 resides on R4. Configure the Token Ring segments at this time. Assign 
the management interface of the token ring switch the IP address of 10.10.10.10. 


Configure a full-duplex, ISL trunk on port 1/1. Set Spanning Tree so that the root for 
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VLAN 2 is always your switch. You might or might not have another switch to connect 
to in this lab. This will not impact your configuration. 


. Configure VTP, such that VTP updates will be listened to and forwarded, but not used 
to update the VLAN database. 


Section Ill: OSPF and Frame Relay Configuration 


. Configure the Frame Relay network as shown on Figure 18-6. 


. R2, R3, and R4 should share the same IP subnet; configure OSPF Area 10 between 
the routers. 


. Configure VLAN 1 to be in OSPF Area 0. Configure R2's Ring 2 in Area 100. Configure 
the HDLC link between R1/R2 to be in Area 30. 


. Configure Type I] Authentication between R1 and R2. Use Ibu as the password. 


Log any OSPF adjacency changes on the backbone area. 


Section IV: Routing Protocols and Redistribution 


1. Configure |GRP on VLAN 2 and on the Frame Relay circuit between R4/R8; use 2010 


as the Autonomous System ID. Ensure full 1P reachability to the OSPF network. 


. Configure the PPP backup link on R4/R8 to become active only upon loss of Frame 
Relay service. The PPP link should pass all routes; you may not use a static route for 
this. 


Prevent the route of the Token Ring network on R8 from reaching R4 The ISDN should 
not excessively dial and only work during a loss of Frame Relay service. 


Section V: ISDN Configuration 


. Configure the ISDN interfaces on R4 and R6. Be sure that you can ping the R4/R6's 
ISDN interfaces before moving on. 


. Configure CHAP authentication on the ISDN link. Use ccie as the password. 


. Configure the ISDN interfaces as part of the OSPF domain. Put the interfaces in OSPF 
Area 20. The ISDN should not excessively dial and work only during a loss of Frame 
Relay service. 


Section VI: IPX Configuration 


1. Configure IPX on VLAN 1, VLAN 2, Ring 2, and Ring 8. 


2. Configure |PX EIGRP on R1, R2, R3, and R6. Create a tunnel from R3 to R4 across the 
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Frame Relay network. Ensure that all the IPX networks are visible on all routers. 


3. Configure |PX RIP/SAP between R4 and R8 across the Frame Relay network. Make I PX 
traffic from R4 to R8 use a separate PVC from IP traffic. 


4. Configure IPX SAP on Ring 2, which supports print services. This SAP is called 
fakeprint and has socket 451. Ensure that R4 can see this SAP. 


5. Apply a static SAP to R6 that is three hops away. The SAP offers print services and 
should be configured as such. 


Section VII: Bridging 


1. Transparently bridge SNA from VLAN 1 to VLAN 2 across the Frame Relay network. 
Make R4 the root of the Spanning Tree. 


2. Bridge and route IPX on VLAN 2 of R4. 
Section VIII: Miscellaneous Cisco IOS Software Configuration 


1. Configure custom queuing on R4 with the following guidelines: EIGRP, OSPF, and IPX 
traffic have an average packet size of 500 and need 25 percent of the link. WWW 
traffic has an average packet size of 1412 and will get 10 percent of the link. The 
average packet size for the default queue is 700 and will get 65 percent of the link. 
Assign the queue the Frame Interface. 


2. The subnet 10.10.10.0/24 on R8 should not be circulated by any routing protocol. 
There are two hosts on this network, 10.10.10.5 and 10.10.10.10. These hosts need 
full reachability to the lab network. Allow these two hosts to have the same IP address 
each time they are translated. 


3. A mainframe resides on VLAN 2. It has three IP addresses; 165.10.10.100, 
165.10.10.101, and 165.10.10.102. These IP addresses correspond to a single MAC 
address of 2200.0001.0001. Configure the router, R4, to support forwarding traffic to 
the single MAC address for all three IP addresses. 
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Part II 


Section IX: BGP configuration 


1. R1, R3, and R6 are in autonomous system 2001. R2 is in autonomous system 5, and 
R4 is in autonomous system 2010. Configure an EBGP peer from R2 to R1. Also 
configure an EBGP from R2 to R4 and from R3 to R4 so that there are three exit 
points from AS 2001. 


2. On R4, assign and advertise the loopback network 200.128.1.0/24 through BGP. On 
R2, advertise the loopback network of 172.16.1.0/24 through BGP. 


3. Configure IBGP from R1 to R3 and from R1 to R6; do not configure a peer from R3 to 
R6. Ensure that all BGP routers are receiving these routes. 


Section X: DLSw Configuration 


1. Configure a DLSw FST peer between R2, Ring 2, and R8, Ring 8. Filter all NetBIOS 
names starting with the letters "lab" between Ring 2 and Ring 8. 


2. Configure a DLSw TCP peer between R2, Ring 2, and R6, VLAN 1. 


3. If R2 loses its peer to R6, have another peer become active, pointing at R1. R2 should 
not have a "connected" peer and connectivity to Rl unless the peer from R2 to Ré6 is 
lost. The peer from R2 to R1 should terminate LLC2 sessions five minutes after TCP 
connectivity is restored from R2 to R6. 


Section XI: Miscellaneous Cisco lOS Software Features 


1. Configure static RIF of R8 so that it looks like the following: 
Ring8- Bridge7-Ring9-Bridge11-Ring10-host—2200.600E.900E MAC address 


2. Configure R2 as an NTP server. Synchronize the clock of R6 to R2. Authenticate NTP 
with MD5 encryption. Use cisco as the password, and a stratum of 6. 


3. Configuring priority queuing on the frame interface of R3. Assign Telnet, OSPF, and 
IPX to the high-priority queue, and assign WWW to the low- priority queue. Everything 
else should be assigned the default. 
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CCIE Practice Lab: "The Enchilada" 
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Equipment List 


One Frame Relay switch: five serial ports 
One Access Server: 10 asynchronous interfaces, 1 Ethernet port 


Two Cisco 3810s or 3600s: one Ethernet, one serial interface, one FXS port with 
telephone headset 


One lab router: one Token Ring, one serial interface, one ISDN BRI 


One lab router: one Ethernet port, one Token Ring, one serial interface, one ISDN BRI 


Two lab routers: one Ethernet port, one ATM interface 


One lab router: one 100-MB Ethernet port, one serial port 


One Catalyst 3900 
One Catalyst 5000 
One ATM switch 
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Prestaging: Frame Switch Configuration 


Configure the Frame Relay switch with the PVCs as depicted in Figure 18-7; do not time 
yourself on this portion of the lab. Example 18-6 lists the configuration for the Frame switch. 


Figure 18-7. Frame Relay Switch Configuration 
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Example 18-6 Frame Relay Switch Configuration 


hostname frame_switch 
! 
frame-relay switching 
! 
<<<text omitted>>> 
! 
interface Serial0 
no ip address 
encapsulation frame-relay 
no fair-—queue 
clockrate 148000 
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frame-relay lmi-type ansi 

frame-relay intf-type dce 

frame-relay route 121 interface Seriall 120 
! 

interface Seriall 

no ip address 

encapsulation frame-relay 

clockrate 148000 

frame-relay intf-type dce 

frame-relay route 110 interface Serial5 111 
frame-relay route 120 interface SerialO 121 
frame-relay route 130 interface Serial3 131 
frame-relay route 140 interface Serial2 141 
! 
interface Serial2 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay intf-type dce 

frame-relay route 141 interface Seriall 140 
! 
interface Serial3 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay intf-type dce 

frame-relay route 131 interface Seriall 130 
! 
interface Serial5 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay intf-type dce 

frame-relay route 111 interface Seriall 110 


The following portions of the lab are timed, and the lab should begin after the configuration 
and physical installation of the Frame switch and the backbone router. Do not configure any 
other routers at this time. 
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Timed Portion 


Lab Rules 


No static routes or floating static routes are used unless specifically stated. 

Follow the instructions exactly. Be careful to propagate routes only where and when 
instructed. Use the PVCs only as directed by the instructions. 

Primary configurations might need to be modified for Part || only when you have finished 
the primary configurations. 

You can use the configuration guides and the Cisco Documentation CD-ROM for your only 
reference material. 

You have 8 1/2 hours to complete the lab. Do not talk to anyone during this phase. 

It is recommended that you read the entire lab before beginning. 

Make an accurate and precise network illustration. 

Use Figure 18-8 as a reference for the physical layout of the lab. 


Figure 18-8. Network Diagram for "The Enchilada" 
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Section I: Basic IP Configuration 
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1. Access server: Configure the access server/router so that all the routers and the switches 
can be accessed through reverse Telnet. Password-protect all routers and switches with 
the password cisco. 


2. IP address assignment: Assign an IP addresses to all physical interfaces, as denoted in 
Figure 18-8. Use the major network of 155.100.x.x on all interfaces. Use a 24-bit mask on 
all interfaces except for the following: 


R1: Use a 25-bit address on VLAN 1 between R1 and R95. 
R2: Use a 27-bit address on VLAN 20. 

R3: Use a 28-bit address on VLAN 30. 

R4: Assign Ring 2 an IP address of 10.11.10.0/24. 


3. Full IP and 1PX connectivity to all Ethernet, Token Ring, and loopback interfaces will be 
expected unless noted. 


4. Document the network thoroughly; include all OSPF areas, |P/IPX address, IPX networks, 
and so on. 


Section II: Catalyst/LAN Configuration 


1. Configure the VLANs as depicted in Figure 18-8. VLAN 70, VLAN 80, and VLAN 90 reside 
off the 100-MB port on R7. Configure the router to route between the VLANs. 


2. Configure the Catalyst Ethernet and Token Ring switches so that they can be managed 
through Telnet from any router in the lab. 


3. Configure the Token Ring segments at this time. Do not use the default Token Ring VLAN. 


4. Configure a full-duplex 802.1Q trunk on port 1/1 of the Catalyst switch. Prevent STP for 
VLANs 70, 80, and 90 from being propagated down this trunk. It is not important whether 
this link is attached; the configuration of the switch will be the same. 


Section Ill: OSPF and Frame Relay Configuration 
1. Configure the Frame Relay network as shown in Figure 18-8. 


2. R1, R2, and R3 should share the same IP subnet; use subinterfaces only on R1. Configure 
this subnet to be in Area 0. Do not change the OSPF network type on R1. Configure the 
Frame Circuit between R1 and R7 to be in OSPF Area 10. 


3. Configure VLAN 20 to be in OSPF Area 20. Configure VLAN 30 to be in OSPF Area 30. 
Configure VLANs 70, 80, 90 to be in OSPF Area 70. 


4. Configure Area 30 to send link-state type 7's, to any new OSPF routers that might be on 
VLAN30. 


5. Authenticate Area 0 with Type II authentication. Use cisco as the password. 
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Section IV: Routing Protocols and Redistribution 


1. Configure |GRP on Ring 2 and on the Frame Relay circuit between R1/R4. Ensure full IP 
reachability to the OSPF network. 


2. Prevent the subnet of the Token Ring network on R4 from reaching R7. 
Section V: ATM and EIGRP 


1. R5 and R6 both connect to the ATM switch. Configure classical |P over ATM between the 
routers so that the routers can ping each other. 


2. Configure EIGRP on VLAN 1 of R5 and over the ATM cloud to R6. Redistribute EIGRP into 
OSPF. Make sure that the entire EIGRP network is reachable from the |GRP and OSPF 
domains. 


Section VI: ISDN Configuration 


1. Configure the ISDN interfaces on R1 and R4. Make only R4 place the call to Rl. Be sure 
that you can ping the R1/R4's ISDN interfaces before moving on. 


2. Configure the ISDN interfaces as part of the |GRP backbone. Ensure that the link becomes 
active only upon loss of |GRP routes from R1. 


Section VIl: Voice over IP 


1. Configure Voice over IP between R2 and R3. Use the FXS ports to create a ringdown circuit 
between the two routers. 


Section VIll: IPX Configuration 


1. Configure IPX on VLAN 1, VLAN 20, and VLAN 30. 


2. Configure IPX EIGRP on R1, R2, R3, and R5. Configure IPX on Ring 2 of R4; use |PX RIP/ 
SAP on the frame link between R4 and R1. Ensure that all routers see all |PX networks. 


3. Configure IPX SAP on R5, which supports file services. This SAP is called fakefserver and 
has socket 452. Ensure that all routers can see this SAP. 


4. On R2, apply a SAP filter blocking all SAPs that start with the letters "fake." 
5. Configure VLAN 30 so that SAPs are advertised only when a new server comes online. 


Section IX: Miscellaneous Cisco lOS Software Configuration 


1. Workstations on VLAN 20 need to gain their |1P addresses through the DHCP server on 
VLAN1. Configure R2 to support this. 


2. Configure R3 so that workstations VLAN 30 can dynamically locate their default gateway. 
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They are not using DHCP. 


. Configure multicast routing on R1, R2, and R5. Configure R1 as a member of the multicast 
group 224.0.7.7. Rl should respond to pings from R2 and R5. 


. Configure R1, R2, and R5 to dynamically configure the Cat5k for multicast. 
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Part II 


Section X: BGP Configuration 


1. R2, and R7 are in autonomous system 2001. R5 is in autonomous system 5, and R4 is 
in autonomous system 4. Configure an IBGP peer from R2 to R7. Also configure an 
EBGP from R2 to R5 and from R7 to R4. 


2. On R4, assign and advertise the loopback network 220.128.1.0/24 through BGP. On 
R5, assign and advertise the loopback network 24.128.1.0/24, 24.128.2.0/24 through 
BGP. 


3. Have R5 advertise a default route to the ATM network if—and only if—it has the route 
220.128.1.0/24. 


4. Configure R4 so that all routes from AS 2001 have a weight of 350. 
Section XI: DLSw Configuration 


1. Configure a DLSw TCP peer from R1, VLAN 1 to R2, VLAN 20. On VLAN 20, there is an 
SNA host with the MAC address of 2200.900e.0001. Allow only explorer frames 
destined toward this address to cross the DLSw peer. 


2. Configure a DLSw TCP peer between R4, Ring 2, and R1, VLAN 1. 


3. Allow the peer on R4 to stay "connected," even upon a loss of the Frame Service. It 
might take up to three minutes for the network to converge over the ISDN link. The 
peer should not become disconnected during this time. 


Section XII: Miscellaneous Cisco l|OS Software Features 


1. Transparently bridge from VLAN 30 to VLAN 1, across the Frame Relay cloud. 


2. Configure R1 as an NTP server. Configure a peer association so that R4 synchronizes 
to R1. When R4 is synchronized, allow R2 and R3 to synchronize off R4. If R4 is not 
synchronized with R1, R2 and R3 should not synchronize. 


3. Bridge and route IPX on VLAN 30. 
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CCIE Practice Lab: "The Unnamed Lab" 
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Equipment List 


One Frame Relay switch: three serial ports 


One access server: eight asynchronous interfaces, one Ethernet port 


Two lab routers: one Ethernet, two serial interfaces, one ISDN BRI 


Two lab routers: one Token Ring, one Ethernet, one serial interface 


Two lab routers: one Ethernet port, one serial interface 


Two lab routers: one Ethernet port, one ATM interface 


One Catalyst 3900 
One Catalyst 5000 
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Prestaging: Frame Switch Configuration 


Configure the Frame Relay switch with the PVCs as depicted in Figure 18-9; do not time 
yourself on this portion of the lab. Example 18-7 lists the configuration for the Frame Relay 
switch. 


Figure 18-9. Frame Relay Switch Configuration 
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Example 18-7 Frame Relay Switch Configuration 


hostname frame_switch 
! 

frame-relay switching 
! 

<<<text omitted>>> 

! 

interface Serial0 

no ip address 
encapsulation frame-relay 
no fair-—queue 
clockrate 148000 
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frame-relay lmi-type ansi 

frame-relay intf-type dce 

frame-relay route 121 interface Seriall 120 
frame-relay route 141 interface Serial3 140 
! 

interface Seriall 

no ip address 

encapsulation frame-relay 

clockrate 148000 

frame-relay intf-type dce 

frame-relay route 120 interface SerialO 121 
frame-relay route 130 interface Serial3 131 
! 
interface Serial3 

no ip address 

encapsulation frame-relay 

clockrate 64000 

frame-relay intf-type dce 

frame-relay route 131 interface Seriall 130 
frame-relay route 140 interface SerialO 141 


The following portion of the lab is timed, and it should begin after the configuration and 
physical installation of the Frame switch and the backbone router. Do not configure any other 
routers at this time. 
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Prestaging: Backbone Router Configuration 


Configure a backbone router and attach it to Backbone 1. Example 18-8 illustrates the 
configuration of the backbone router. 


Example 18-8 Backbone Router Configuration 


hostname r6_backbone_router 
! 
interface Loopback20 
ip address 192.190.100.1 255.255.255.0 
! 
interface Loopback21 
ip address 192.190.101.1 255.255.255.0 
! 
interface Loopback22 
ip address 192.190.102.1 255.255.255.0 
! 
interface Loopback23 
ip address 160.100.100.1 255.255.255.0 
! 
interface Loopback24 
ip address 160.100.128.1 255.255.255.0 
! 
interface Loopback25 
ip address 160.100.129.1 255.255.255.0 
! 
interface Loopback26 
ip address 160.100.130.1 255.255.255.0 
! 
interface Ethernet0 
description place on vlan 2 —- Backbone 2 
ip address 133.7.77.254 255.255.255.0 
media-type 10BaseT 
! 
interface Ethernetl 
description place on vlan 10 - backbone 1 
ip address 160.100.2.254 255.255.255.0 
media-type 10BaseT 
! 
router rip 
no auto-summary 
network 160.100.0.0 
network 192.190.100.0 
network 192.190.1001. 


network 192.190.102.0 
! 


oO 


router bgp 2001 

no synchronization 

network 160.100.100.0 mask 255.255.255.0 
network 160.100.128.0 mask 255.255.255.0 
network 160.100.129.0 mask 255.255.255.0 
network 160.100.130.0 mask 255.255.255.0 
neighbor 160.100.2.1 remote-as 2010 
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neighbor 160.100.2.1 ebgp-multihop 10 
! 


The following portion of the lab is timed, and it should begin after the configuration and 
physical installation of the Frame Relay switch and the backbone router. Do not configure any 


other routers at this time. 


1136 


Timed Portion 
Lab Rules 


e No static routes or floating static routes are used unless specifically stated. 

e Follow the instructions exactly. Be careful to propagate routes only where and when 
instructed. Use the PVCs only as directed by the instructions. 

e Primary configurations might need to be modified for Part Il only when you finish the 
primary configurations. 

e You can use the configuration guides and the Cisco Documentation CD-ROM for your 
only reference material. 

e You have 8 1/2 hours to complete this portion of the lab. Do not talk to anyone during 
this phase. 

e It is recommended that you read the entire lab before beginning. 

Make an accurate and precise network illustration. 

e Use Figure 18-10 as a reference for the physical layout of the lab. 


Section I: Basic IP Configuration 


1. Access server: Configure the access server/router so that all the routers and the 
switches can be accessed through reverse Telnet. Password- protect all routers and 
switches with the password cisco. 


2. IP address assignment: Assign an IP addresses to all physical interfaces, as denoted 
in Figure 18-10. Use the major network of 133.7.x.x on all interfaces. Configure a 


loopback address on each router; use 133.7.x.x, where x.x is the router number. For 
example, R5's loopback would be 133.7.5.5. Use a 24-bit mask on all interfaces 
except for the following: 


R1: Use the IP address of 160.100.2.1/24 on the Ethernet segment; 
use VLAN 10 for this segment. 


R2, R3, R6: Use a 22-bit address on VLAN 30 between all the routers. 
R3: Use a 26-bit address on Ring 1. 


R4: Use the IP address of 10.10.10.1 on Ring 2. Allow the subnet on 
the ring to have 14 hosts on it. Use the IP address of 133.7.77.1/24 on 
VLAN 2. 


R5: Use a 26-bit address on VLAN 55. 


3. Full 1P and I1PX connectivity to all Ethernet, Token Ring, and loopback interfaces will 
be expected unless noted. 


4. Document the network thoroughly; include all OSPF areas, |P/IPX address, IPX 
networks, and so on. 


Section Il: Catalyst/LAN Configuration 
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1. Configure the VLANs as depicted in Figure 18-10. Assign an IP address of 


133.7.10.254 to the Catalyst. Configure the Catalyst switch that so it can be managed/ 
telnetted from any router in the lab. 


2. Configure the Catalyst ports in VLAN 30 so that they will work only with R2, R3, and 
R6. If any other device is plugged into these ports, have the Catalyst deactivate the 
port. 


3. Configure the Catalysts so that if the backplane of the switch gets overloaded, the 
ports in VLAN 30 get serviced before the ports on VLAN 55. 


4. Password-protect VTP. Use the password of Cisco_CCIE. 


Section Ill: OSPF and Frame Relay Configuration 


1. Configure the Frame Relay network as shown on Figure 18-10. Do not allow any 
dynamic PVC mapping from R1 to R5. 


2. Rl, R3, and R5 should share the same IP subnet. Configure this subnet to be in Area 
10. 


3. Configure VLAN 30 to be in OSPF Area 0. Configure VLAN 55 to be in OSPF Area 55. 


4. Configure Ring 1 of R3 to be in Area 20. Configure the ISDN network between R5 and 
R2 to be in Area 100. 


Section IV: Routing Protocols and Redistribution 


1. Configure |GRP on HDLC circuit between R2/R4 and on Backbone 2. Redistribute IGRP 
into OSPF. Do not put Ring 2 into any routing protocol. 


2. Advertise a default route to R4's Backbone 2 without configuring summarization or 
using a static route. Ensure that every interface on R4 except Ring 2 has complete IP 
connectivity to the lab network. 


3. Configure RIP on R1's Ethernet segment or Backbone 1. Some routes will come from 
the backbone network. They are 192.190.100.0/24, 192.190.101.0/24, and 
192.190.102.0/24. Advertise these as one network into the rest of lab network. 


4. Prevent all lab routes from being broadcast unto the Backbone 1 segment. 


5. Ensure full 1P reachability between OSPF, IGRP, and RIP domains, except for the 
network on Ring 2. 


Section V: ATM and EIGRP 
1. Configure the ATM interface on R6 to be part of the EIGRP autonomous system 2010. 
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2. Configure R6 so that it can ping the ATM lab router without using Inverse ARP. 
3. Configure MD5 authentication for EIGRP AS 2010. 


Section VI: ISDN Configuration 


1. Configure the ISDN interfaces on R2 and R5. Configure the ISDN calling so that only 
R5 can place a call. Use CHAP authentication; use ciscoll as the password. Ensure 
that you can ping the local ISDN interfaces before moving on. 


2. Configure the ISDN interfaces as part of the OSPF domain. Ensure that the link 
becomes active only upon changes in the routing table, unless otherwise stated. Only 
TCP traffic should bring up the link; routing updates should not. 


Section VII: IPX Configuration 


1. Configure IPX networks on all interfaces except the loopbacks, ISDN network, 
Backbone 2, and the ATM network. 


2. Configure |PX NLSP on the HDLC network on R2/R4 and on Ring 2. Use |PX RIP on 
VLAN 30. Use IPX EIGRP on Frame, VLAN 55, and on Backbone 1 of R1. Ensure that 
all routers have IPX reachability to all |PX networks. 


3. Configure IPX SAP on R5, which supports print services. This SAP is called fakepserver 
and has socket 451. Ensure that all routers can see this SAP. 


4. Configure R2 so that the IPX network assigned to VLAN 55 will not be propagated to 
R4. 


Section VIII: Miscellaneous Cisco IOS Software Configuration 


1. The IP network assigned to Ring 2 should not be advertised by any routing protocol. 
Allow the users of this ring to have full |P reachability to the lab network without 
using redistribution, static routes, or default routes. 


2. Deny R1 from pinging R2, but allow R2 to ping R1. 
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Part II 


Section IX: BGP Configuration 


1. R1, R2, and R6 are in autonomous system 2010. R4 is in autonomous system 2020. 
The Backbone 1 router is in autonomous 2001. Configure an IBGP peer from R1 to R2 
and from R2 to R6. 


2. Configure an EBGP peer from R2 to R4. Configure an EBGP peer from R1 to the 
Backbone 1 router, 160.100.2.254, in autonomous system 2001. 


3. Synchronize BGP with OSPF. 
4. On R4 assign and advertise the 10's network through BGP. 


5. Three subnets are being advertised from the backbone router: 192.190.100.0 to 
192.190.102.0. Summarize the subnets into the supernet of 192.0.0.0/8. Advertise 
only this subnet and suppress all other routes. 


Section X: DLSw Configuration 


1. Configure a DLSw TCP peer between R3, Ring 1, and R5, VLAN 55. Configure another 
TCP peer from R3 to R1's Backbone 1. 


2. Allow only NetBIOS reachability from Ring 1 to Backbone 1. 
3. Configure R5 to advertise local reachability to a server called unnamed. 
Section XI: Miscellaneous Cisco IOS Software Features 


1. Configure R5 so that IP ping traffic from VLAN 55 destined toward VLAN 30 will take 
the ISDN link. All other IP traffic will take the frame circuit. 


2. Configure R4 so that only SNA traffic to MAC address 3745.0001.0001 is allowed on 
Ring 2. 


3. Configure R1 so that when the user unnamed logs into the router, that user 
immediately is put in enable mode. 


4. Configure the access server so that the reverse Telnet sessions to the routers in the 
lab will never time out. 
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Part IX: Appendixes 


Appendix A ISDN Switch Types, Codes, and Values 
Appendix B The 'Abridged' OSI Reference Model 
Appendix C RFC List 

Appendix D Common Cable Types and Pinouts 


Appendix E Bibliography 
Part |X Appendixes 
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Appendix A. ISDN Switch Types, Codes, and Values 


This appendix contains a list of the supported switch types. It also contains the ISDN cause 
codes, cause values, bearer capability values, and progress description field values that are 
valid within the debug commands for ISDN. 


NOTE 


The ITU-T carries out the functions of the former Consultative Committee for 
International Telegraph and Telephone (CCITT). 


1142 


Switch Types 


Table A-1 lists the ISDN switch types supported by the ISDN interface. 


Table A-1. Supported ISDN Switch Types 


| I dentifier | Description 


basic- 1tr6 German 1TR6 ISDN switches 

basic-5ess AT&T basic rate switches 

basic-dms100 INT DMS-100 basic rate switches 

basic-net3 NET3 ISDN and Euro-ISDN switches (UK and others), also 
called E-DSS1 or DSS1 

basic-nil National ISDN-1 switches 


basic-nwnet3 Norway Net3 switches 


basic-nznet3 [New Zealand Net3 switches 

basic-ts013 Australian TS0O13 switches 

Nem INo switch defined 

Intt | apanese NTT ISDN switches (ISDN BRI only) 


AT&T 4ESS switch type for the United States (ISDN PRI 
primary-4ess only) 

AT&T 5ESS switch type for the United States (ISDN PRI 
primary-5ess only) 


NT DMS-100 switch type for the United States (ISDN PRI 
only) 


NET5 ISDN PRI switches (Europe) 
INS-Net 1500 for Japan (ISDN PRI only) 
primary-tsO14 |Australian TSO14 switches (ISDN PRI only) 


vn2 French VN2 ISDN switches (ISDN BRI only) 
vn3 French VN3 ISDN switches (ISDN BRI only) 
vn4 French VN4 ISDN switches (ISDN BRI only) 
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Cause Code Fields 


Table A-2 lists the ISDN cause code fields that display in the following format within the 
debug commands: 


i=Ox yl y2 zl z2 [al a2] 


Table A-2. ISDN Cause Code Fields 


| Field | Value—Description 


The values that follow are in hexadecimal. 
8— ITU-T standard coding. 


Class (the more significant hexadecimal number) of cause value. 
Refer to Table A-3 for detailed information about possible values. 


Value (the less significant hexadecimal number) of cause value. Refer 
to Table A-3 for detailed information about possible values. 


la 1 (Optional) Diagnostic field that is always 8. 


a 
O— User 
1— Private network serving local user 
2— Public network serving local user 
3— Transit network 
4— Public network serving remote user 
5— Private network serving remote user 
7— International network 
A— Network beyond internetworking point 
_ 
~ 
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a2 (Optional) Diagnostic field that is one of the following values: 


o— Unknown 


1— Permanent 


2— Transient 


The following is sample output of this form from the debug isdn q931 command: 


Cause 1 = 0x8790 
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Cause Values 


Table A-3 lists descriptions of the cause value field of the cause information element. The 
notes referred to in the Diagnostics column follow the table. For the debug isdn q931 
command output, drop the highest bit of the cause value before using this table. For 


example, a cause value of 0x90 becomes 0x10. 


Table A-3. ISDN Cause Values 


Decimal Hex 
ae we Cause 


Unallocated 
(unassigned) 
number 

No route to 
specified transit 
network 


No route to 
destination 


Channel 
unacceptable 


Diagnostics 


| Explanation 


The ISDN number 
was sent to the 
switch in the 
correct format; 
however, the 
number is not 
assigned to any 
destination 
equipment. 


The ISDN 
exchange is 
asked to route 
the call through 
an unrecognized 
intermediate 
network. 


The call was 
routed through 
an intermediate 
network that 
does not serve 
the destination 
address. 


The service 
quality of the 
specified channel 
is insufficient to 
accept the 
connection. 


Transit network 
identity (Note 
9) 
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Call awarded and 
being delivered in 
an established 
channel 


Normal call clearing 


User busy 


No user responding 


No answer from 
user (user alerted) 


Call rejected 


7 


_ 10 


- 


Note 10; user 
supplied 
diagnostic 
(Note 4) 


The user is 


assigned an 
incoming call that 
is being 
connected to an 
already- 
established call 
channel. 


Normal call 
clearing has 
occurred. 


The called system 
acknowledges the 
connection 
request but is 
incapable of 
accepting the call 
because all B 
channels are in 
use. 


The connection 
cannot be 
completed 
because the 
destination does 
not respond to 
the call. 


The destination 
responds to the 
connection 
request but fails 
to complete the 
connection within 
the prescribed 
time. The 
problem is at the 
remote end of 
the connection. 


The destination is 
capable of 
accepting the 
call, but it 
rejected the call 
for an unknown 
reason. 
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Number changed The ISDN number 
used to set up 
the call is not 
assigned to any 


system. 


The destination is 
capable of 
accepting the 
call, but it 
rejected the call 
because it was 
not assigned to 
the user. 


The destination 
cannot be 
reached because 
the interface is 
not functioning 
correctly anda 
Signaling 
message cannot 
be delivered. This 
might be a 
temporary 
condition, but it 
could last for an 
extended period 
of time. For 
example, the 
remote 
equipment might 
be turned off. 
The connection 
could not be 
established 
because the 
destination 
address was 
presented in an 
unrecognizable 
format or 
because the 
destination 
address was 
incomplete. 


Nonselected user 
clearing 


Designation out of 
order 


cemmarlsmamenrnkeemnlir 
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Facility rejected 


Facility 
identification 
(Note 1) 


The facility 
requested by the 
user cannot be 
provided by the 
network. 


The status 
message was 
generated in 
direct response to 
the previous 
receipt of a 

status inquiry 
message. 


Reports the 
occurrence of a 
normal event 
when no standard 
cause applies. No 
action is 

required. 


The connection 
cannot be 
established 
because no 
appropriate 
channel is 
available to take 
the call. 


The destination 
cannot be 
reached because 
the network is 
not functioning 
correctly, and the 
condition might 
last for an 
extended period 
of time. An 
immediate 
reconnect 
attempt will 
probably be 
unsuccessful. 


Response to 
STATUS ENQUIRY 


LF 


Normal, unspecified 


No circuit/channel 
available 


Network out of 
order 
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41 Temporary failure An error occurred 
because the 
network is not 
functioning 
correctly. The 
problem will be 
resolved shortly. 

42 2A Switching The destination 

equipment cannot be 

congestion reached because 
the network- 
switching 
equipment is 
temporarily 
overloaded. 

43 2B Access information /|Discarded The network 

discarded cannot provide 

Note 5) 
44 2C Requested circuit/ 

channel not equipment 

available cannot provide 
the requested 
channel for an 
unknown reason. 

47 ZF Resources 

unavailable, channel or 

unspecified service is 
unavailable for an 
unknown reason. 

49 cal Quality of service Table A-2 

unavailable quality of service 


cannot be 
provided by the 
network. This 
might be a 
subscription 
problem. 
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Requested facility 
not subscribed 


Facility The remote 

identification equipment 

(Note 1) supports the 
requested 
supplementary 
service by 
subscription only. 


Bearer capability Note 3 The user 

not authorized requested a 
bearer capability 
that the network 
provides, but the 
user is not 
authorized to use 
it. This might be 
a subscription 


problem. 
Bearer capability Note 3 The network 
not presently normally provides 
available the requested 


bearer capability, 
but it is 
unavailable at the 
present time. 
This might be the 
result of a 
temporary 
network problem 
or toa 
subscription 
problem. 


Service or option The network or 

not available, remote 

unspecified equipment was 
incapable of 
providing the 
requested service 
option for an 
unspecified 
reason. This 
might be a 
subscription 
problem. 
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The network 
cannot provide 
the bearer 
Capability 
requested by the 
user. 


The network or 
the destination 
equipment does 
not support the 
requested 

channel type. 


The remote 
equipment does 
not support the 
requested 
supplementary 
service. 


The network is 
incapable of 
providing 
unrestricted 
digital 
information 
bearer capability. 


The network or 
remote 
equipment is 
incapable of 
providing the 
requested service 
option for an 
unspecified 
reason. This 
might be a 
subscription 
problem. 


The remote 
equipment 
received a Call 
with a call 
reference that is 
not currently in 
use on the user- 
network 
interface. 


Bearer capability 
not implemented 


Channel Type 
(Note 6) 


Requested facility 
not implemented 


(Note 1) 


Only restricted 
digital information 
bearer capability is 
available 


Service or option 
not implemented, 


Invalid call 
reference value 
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Channel 
identity 


Identified channel 
does not exist 


The receiving 
equipment is 
requested to use 
a channel that is 
not activated on 
the interface for 
Calls. 


The network 
received a call 
resume request. 
The call resume 
request contained 
a Call identify 
information 
element that 
indicates that the 
call identity is 
being used for a 
suspended call. 


The network 
received a Call 
resume request. 
The call resume 
request contained 
a Call Identify 
information 
element that 
indicates that it is 
in use fora 
suspended call. 


The network 
received a call 
resume request 
when there was 
not a suspended 
call pending. This 
might be a 
transient error 
that will be 
resolved by 
successive Call 
retries. 


A suspended call 
exists, but this call 
identity does not 


Call identity in use 


No call suspended 


1153 


5B 


oir 


Invalid transit 
network selection 


Invalid message, 
unspecified 


Clearing cause 


Incompatible 


The network 
received a Call 
resume request. 
The call resume 
request contained 
a Call identity 
information 
element, which 
once indicated a 
suspended call. 
However, the 
suspended call 
was cleared 
either by timeout 
or by the remote 
user. 


This indicates 
that an attempt 
was made to 
connect to non- 
ISDN equipment— 
for example, to 

an analog line. 


The ISDN 
exchange was 
asked to route 
the call through 
an unrecognized 
intermediate 
network. 


An invalid 
message was 
received, and no 
standard cause 
applies. This is 
usually the result 
of a D-channel 
error. If this error 
occurs 
systematically, 
report it to your 
ISDN service 
provider. 
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element is missing — |identifier(s) 
(Note 5) 


97 Message type Message type 
nonexistent or not 
implemented 


98 62 Message not Message type 
compatible with call 
state or message 
type nonexistent or 
not implemented 


The receiving 
equipment 
received a 
message that did 
not include one of 
the mandatory 
information 
elements. This is 
usually the result 
of a D-channel 
error. If this error 
occurs 
systematically, 
reportit to your 
ISDN service 
provider. 


The receiving 
equipment 
received an 
unrecognized 
message, either 
because the 
message type 
was invalid or 
because the 
message type 
was valid but not 
supported. The 
cause is either a 
problem with the 
remote 
configuration or a 
problem with the 
local D channel. 


The remote 
equipment 
received an 
invalid message, 
and no standard 
Cause applies. 
This cause is a D- 
channel error. If 
this error occurs 
systematically, 
report it to your 
ISDN service 
provider. 
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100 


101 


The remote 
equipment 
received a 
message that 
includes 
information 
elements that 
were not 
recognized. This 
is usually the 
result of a D- 
channel error. If 
this error occurs 
systematically, 
report it to your 
ISDN service 
provider. 


The remote 
equipment 
received a 
message that 
includes invalid 
information in the 
information 
element. This is 
usually the result 
of a D-channel 
error. 


The remote 
equipment 
received an 
unexpected 
message that 
does not 
correspond to the 
current state of 
the connection. 
This is usually the 
result of a D- 
channel error. 


identifier(s) 
(Notes 5 and 
7) 


nonexistent or not 
implemented 


64 Information 
element 
identifier(s) 


(Note 5) 


Invalid information 
element contents 


65 


Message not 
compatible with call 
state 
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Recovery on timer |Timer number — {An error-handling 

expires (Note 8) (recovery) 
procedure was 
initiated by a 
timer expiry. This 
is uSually a 
temporary 
problem. 


Protocol error, This is the result 

unspecified of an unspecified 
D-channel error 
when no other 
standard cause 


Internetworking, 

unspecified occurred, but the 
network does not 
provide causes 
for the action 
that it takes. The 
precise problem 
is unknown. 


Note 1— The coding of facility identification is network-dependent. 


Note 2— An incompatible parameter is composed of an incompatible information element 
identifier. 


Note 3— The format of the diagnostic field for causes 39, 3A, and 41 is shown in the ITU-T 
Q.850 specification, Table 3b/Q.850. 


Note 4— The user-supplied diagnostic field is encoded according to the user specification, 
subject to the maximum length of the cause information element. The coding of user- 
supplied diagnostics should be made in such a way that it does not conflict with the coding 
described in Table A-2. 


Note 5— Locking and nonlocking shift procedures described in the |TU-T Q.931 specification 
apply. In principle, information element identifiers are in the same order as the information 
elements in the received message. 


Note 6— The following coding is used: 
e Bit 8— Extension bit 
e Bits 7 through 5— Spare 
e Bits 4 through 1— According to Table 4-15/Q.931 octet 3.2, channel type in ITU-T 


Q.931 specification 
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Note 7— When only locking shift information element is included and no variable-length 
information element identifier follows, it means that the codeset in the locking shift itself is 
not implemented. 


Note 8— The timer number is coded in |A5 characters. The following coding is used in each 
octet: 


e Bit 8— Spare "0" 


e Bits 7 through 1— IA5 character 


Note 9— The diagnostic field contains the entire transit network selection or network- specific 
facilities information element, as applicable. 


Note 10— See Table A-2 for the coding that is used. 
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Bearer Capability Values 


Table A-4 lists the ISDN bearer capability values that display in the following format within 
the debug commands: 


0Ox8890 for 64 kbps or 0x8890218F for 56 kbps 


Table A-4. ISDN Bearer Capability Values 


—— Value Description 
Indication that the values that follow are in hexadecimal 


88  ——s*ITU- T ITU-T coding standard; unrestricted digital information = ITU-T coding standard; unrestricted digital information = unrestricted digital information 


ae mode, 64 kbps 
aE ea 1, V.110/X.30 


8F ~—~—_——‘|Synchronous, no in-band negotiation, 56 kbps no in- [Synchronous, no in-band negotiation, 56 kbps negotiation, 56 kbps 
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Progress Field Values 


Table A-5 lists the values of the Progress description field contained in the ISDN Progress 
indicator information element. 


Table A-5. 1SDN Progress Description Field Values 


pees Description 
Number P 
The call is not end-to-end ISDN; further call 
progress information may be available in-band. 
The destination address is non-ISDN. 
0000011 |3 The origination address is non-ISDN. 
0000100 |4 The call has returned to the ISDN. 
0001000 |g In-band information or an appropriate pattern 
is now available. 
0001010 |10 A delay in response has occurred at the 
destination interface. 


All other values for the Progress description field are reserved. 
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Appendix B. The ‘Abridged’ OSI Reference Model 


Almost every book on networking has some reference to the OSI reference model; this one 
will be no exception. However, instead of repeating the same text that you've probably 
already read 50 times, | would like to offer a new twist on the model in Table B-1. This 


information is presented here in less then 10 words per level, as an "abridged" OSI reference 
model. To read "unabridged" versions, refer to Interconnections, Second Edition: Bridges, 
Routers, Switches, and Internetworking Protocols by Radia Perlman or Networking Standards 
a Guide to OSI ISDN, LAN, and MAN Standards by William Stallings. 


Table B-1. OSI Reference Model Quick Reference 


| OSI Layer | "10-Word Description" 

Application layer |Governs end-user applications and services; FTP, WWW 
browsers, Telnet, SMTP 

Presentation Handles data formats, encoding, and transfer; GIF, J] PEG, 

layer ASCII, EBCDIC, HTML 


Session layer Handles application dialogue control, data grouping, and 
recovery; NFS, SQL, NetBIOS 


Transport layer |Manages network connections; reliable (TCP and SPX) and 
unreliable(UDP) transport 

Network layer Addresses and routes packets, packet fragmentation; 
IPX, AppleTalk 

Data link layer Controls physical layer data flow; Frame Relay, ATM, PPP, 
[EEE 802.x 

fies layer Defines electrical and physical specifications; El A/TIA- 


232, V.35, 10Basex, B8ZS, NRZI 
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Appendix C. RFC List 


Table C-1 provides a list of some of the more common RFCs found throughout the text. The 
complete text version of these RFCs can be found at www.isi.edu. 


Table C-1. List of RFCs 


bai Notes RFC Title 
Number 
RFC 2125 The PPP Bandwidth Allocation Protocol (BAP)\ 
The PPP Bandwidth Allocation Control Protocol 
(BACP) 
RFC 2037. 2037 Entity MIB using SMTv2 


ea 2030 Simple Network Time Protocol (SNTP) 
Version 4 for |Pv4, |Pv6 and OSI 
TCP Selective Acknowledgment 


Options 
BGP Communities Attribute 


RFC 1994 Supersedes RFC 1334 |PPP Challenge Handshake 
Authentication Protocol ae 
RFC 1990 1990 IRFC 1990 ~— |S upersedes RFC 1717 The PPP Multilink Protocol ( 


RFC 1989 Supersedes RFC 1333 _ |PPP Link Quality ee 
Address Allocation for Private 


RFC 1918 
Internets 

RFC 1907 Management Information Base for 
version 2 of the Simple Network 
Management Protocol (SNMPv2) 

RFC 1906 Transport Mappings for Version 2 of 
the Simple Network Management 
Protocol (SNMPv2) 

RFC 1905 Protocol Operations for Version 2 of 


the Simple Network Management 
Protocol (SNMPv2) 


Conformance Statements for Version 2 
of the Simple Network Management 
Protocol (SNMPv2) 


Textual Conventions for Version 2 of 
the Simple Network Management 
Protocol (SNMPv2) 
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Structure of Management Information 
for Version 2 of the Simple Network 
Management Protocol (SNMPv2) 


Supersedes RFCs Introduction to Community-based 
1441-1450 SNMPv2 

RTP: A Transport Protocol for Real- 
Time Applications 


OSPF Version 2 Management 
Information Base 


[RFC 1812 [Requirements for IP Version 4 Routers 

[RFC 1795 IDLSw: Switch-to- Switch Protocol 

RFC 1793 Extending OSPF to Support Demand 
Circuits 


[RFC 1771 | IA Border Gateway Protocol 4 
[RFC 1745 | IBGP4/I DRP for |P—OSPF Interaction 


RIP Version 2 MIB Extension 


RIP Version 2 Carrying Additional 
Information 


RIP Version 2 Protocol Applicability 
Statement 


RPG Ly? Replaced by RFC 1990 The PPP Multilink Protocol (MP) 
RFC 1695 Definitions of Managed Objects for 


ATM Management Version 8.0 Using 
SMI v2 


[RFC 1661 Supersedes RFC 1548 |The PPP (Point-to-Point Protocol) 
[RFC 1647 TN3270 Enhancements 


RFC 1646 Cisco Supports Luname Selection 
Method Only 

RFC 1638 PPP Bridging Control Protocol (BCP) 

RFC 1634 Supersedes 1362 and |Novell |PX over Various WAN Media 

1551 (IPXWAN) 

RFE 1633 Integrated Services in the Internet 
Architecture: an Overview 

RFC. 1631 The IP Network Address Translator 
(NAT) 

[RFC 1618 PPP over ISDN 

RFC 1604 Definitions of Managed Objects for 


Frame Relay Services 


RFC 1587 The OSPF Not-So-Stubby Area (NSSA) 
Option 


RFC 1583 1533 IRFC 1583 [Supersedes RFC 1247 _ Supersedes RFC 1247 | 1247 |OSPF OSPF Version2 ss  s—SsCS 2 


[RFC 1577 | CS EO IP and ARP over ATM 
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TN3270 Current Practices 
DECnet Phase IV MIB Extensions 


The PPP Internetwork Packet 
Exchange Control Protocol (I PXCP) 


|PPP in HDLC Framing 
[RFC 1548 [Replaced by RFC 1661 The Point-to-Point Protocol (PPP) 


RFC 1541 Supersedes RFC 1531 |Dynamic Host Configuration Protocol 
RFC 23531 Replaced by RFC 1541 |Dynamic Host Configuration Protocol 


RFC 1519 Classless Inter-Domain Routing 
(CIDR): an Address Assignment and 
Aggregation Strategy 

peor 1510 The Kerberos Network Authentication 
Service (V5) 


a 1492 An Access Control Protocol, 
Sometimes Called TACACS 


RFC 1490 mae Interconnect over Frame 


RFC 1483 Multiprotocol Encapsulation over ATM 
Adaptation Layer 5 

RFC 1469 IP Multicast over Token-Ring Local 
Area Networks 


RFC 1450 1450 RFC 1450 —‘ [Replaced By RFC 1907 _ By [Replaced By RFC 1907 | 1907 |MIB MIB for SNMP Version2 ————s=i*d SNMP Version 2 


[RFC 1403 HE Foc SNME een OSPF Interaction 


RFC 1397 Default Route Advertisement in BGP2 
and BGP3 Versions Of The Border 
Gateway Protocol 


[RFC 1395 | [BootP Vendor Information Extensions 
[RFC 1393 Traceroute Using anIP Option si Using an IP Traceroute Using anIP Option si 


RFC 1390 Transmission of |P and ARP over FDDI 
Networks 

RFC 1382 SNMP MIB Extension for X.25 Packet 
Layer 


RFC 1381 SNMP MIB Extension for x.25 LAPB 
The PPP AppleTalk Control Protocol 
RFC.1373 (ATCP) 


RPG isy7 The PPP OSI Network Layer Control 
Protocol (OSINLCP) 

RFC 1376 The PPP DECnet Phase IV Control 
Protocol (DNCP) 


Applicability Statement for OSPF 


Novell IPX Over Various WAN Media 
(IXPWAN) 
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RFC: 1356 Multiprotocol Interconnect on x.25 and 
ISDN in the Packet Mode 
[RFC 1350 THE TFTP PROTOCOL (REVISION 2) 


RFC 1349 Type of service in the Internet 
Protocol Suite 


RFC 1348 DNS NSAP RRs 
RFC 1334 Replaced by RFC 1994 |PPP Authentication Protocols 


[RFC 1333 [Replaced by RFC 1989 |PPP Link Quality Monitoring 


ee 1332 The PPP Internet Protocol Control 


Protocol (I PCP) 


' 


RFC 1331 Replaced by FRC 1548 |The Point-to-Point Protocol (PPP) for 
the Transmission of Multi-protocol 
Datagrams over Point-to-Point Links 

[RFC 1323 TCP Extensions for High Performance 

RFC 1315 Management Information Base for 
Frame Relay DTEs 

RFC 1305 Network Time Protocol (Version 3) 
Specification, Implementation and 
Analysis 


RFC 1294 Replaced by RFC 1940 |Multiprotocol Interconnect over Frame 


Relay 
[RFC 1293 


Inverse Address Resolution Protocol 


Definitions of Managed Objects for 
Bridges 


FDDI Management Information Base 


Definitions of Managed Objects for the 
Border Gateway Protocol (Version 3) 


Application of BGP in the Internet 
A Border Gateway Protocol (BGP-3) 


RFC 1256 CMP Router Discovery Messages 


RFC 1253 OSPF Version 2 Management 
Information Base 


RFC 1247 Replaced by RFC 1583 |OSPF Version 2 


RFC 1236 IP to x.121 Address Mapping for DDN 
Tunneling IPX Traffic through IP 

RFC 1234 ae 

RFC 1231 1231 IEEE 802.5 EEE 802.5 Token RingMIB- si EEE 802.5 Token RingMIB- si MIB 


RE ah 1220 Point-to-Point Protocol Extensions for 
Bridging 

| | NG the Assignment of Subnet 

RFC 1219 Numbers 
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RFC 1215 A Convention for Defining Traps for 
use with SNMP 


RPG. 1213 Management Information Base for 
Network Management of TCP/IP-Based 
internets: MIB II 

BFC d212 (Concise MIB Definitions 

RFC 1209 The Transmission of |P Datagrams 
over SMDS Service 

RFC 1196 1196 ) he Finger User Information Protocol | The Finger User Information Protocol | User Information Protocol 

pee tee 1195 _—__{re of OSI IS-IS for Routing in TCP/IP 
and Dual Environments 

RFC 1191 1191 Path MTU Discovery 


ae 1188 Replaced by RFC 1390 |A Proposed Standard for the 
Transmission of |P Datagrams over 
FDDI Networks 


RFC 1172 The Point-to-Point (PPP) Initial 


Configuration Options 

Point Links 
RFC 1163 1163 A Border Gateway Protocol (BGP) 
RFC. 1155 Replaced by FRC 1212 |Structure and Identification of 


RFC 1171 Replaced By RFC 1331 |PPP for the Transmission of Multi- 
INTERNET NUMBERS 

pros — A Simple Network Management 
Protocol (SNMP) 
Management Information for TCP/|IP- 


Protocol Datagrams Over Point-to- 
RFC 1166 
RFC 1164 [Application of the BGP in the Internet 
RFC 1156 1156 RFC 1156 [Replaced by RFC 1213 MIB for TCP/IP 

based Internets 


RFC 1144 Compressing TCP/IP Headers for Low- 
Speed Serial Links 

RFC 1141 Incremental Updating of the Internet 
Checksum 

RFC 1139 An Echo Function for |SO 8473 (ping) 

RFC 1136 Administrative Domains and Routing 
Domains: A model for routing in the 
Internet 


liana t122 Requirements for Internet Hosts— 
Communication Layers 
Obsoletes RFC 119, Network Time Protocol (NTP) Version 
—— 1119/1059, 958 3 


RFC 1112 1112 RFC 1112 | [Host Extensions for IP Multicasting 
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DCA draft IP Security Option (IPSO) 


Re Encoding of Network Names and 
Other Types 

RFC 1091 Telnet Terminal-Type Option 

i 1084 | [BootP Extensions 

RFC 1080 1080 a : Remote Flow Control Option 


pee 1079 Telnet Terminal Speed Option 


RFC 1069 Guidelines for the use of Internet-IP 
addresses in the |SO Connectionless- 
Mode Network Protocol 


[RFC 1060 Assigned Numbers 
[RFC 1058 Routing Information Protocol (RIP) 


Standard for the Transmission of IP 
Datagrams over Serial Lines (SLIP) 


Standard for the Transmission of IP 

Datagrams over IEEE 802 Networks 

RFC 1035 Domain Names—I mplementation and 
Specification 


REC 1034 Domain Names—Concepts and 
Facilities 


RFC 1027 Using ARP to Implement Transparent 
Subnet Gateway (Proxy ARP) 


[RFC 1009 Requirements for Internet Gateways 


RFC 995 Replaced by ISO 9542 |End System to Intermediate System 
Routing Exchange Protocol for use in 
conjunction with |SO 8473 

RFC 994 Replaced by ISO 8473 |Protocol for Providing the 
Connectionless-Mode Network Service 

RFC 982 Guidelines for the Specification of the 


Top of the Structure of the Domain 
Specific Part (DSP) of the I|SO 
Standard NSAP Address 


[RFC 951 | Bootstrap Protocol (BootP) 


RFC 950 Internet Standard Subnetting 
Procedure 

RFC 925 Multi- LAN Address Resolution (PROXY 

| ARP) 


RFC 922 Broadcasting Internet Datagrams in 
the Presence of Subnets (| P-BROAD) 


RFC 919 BROADCASTING INTERNET 
DATAGRAMS 
RFC 906 Bootstrap Loading Using TFTP 
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RFC 904 Exterior Gateway Protocol (EGP) 
Formal Specification 


RFC 903 903 Reverse Address Resolution Protocol 


RFC 896 Congestion Control in TCP/IP 
|Internetworks 


RFC 895 Standard for the Transmission of IP 


Datagrams over Experimental 
boa 894 


Ethernet Networks 


A Standard for the Transmission of IP 
Datagrams over Ethernet 


RFC 891 891 [Hello Protocol 

a 879 The TCP Maximum Segment Size and 
Related Topics 

RFC 877 Standard for the Transmission of IP 
Datagrams over Public Data Networks 

RFC 874 Telnet Protocol Specification 


Discard Protocol 


[Echo Protocol 
TELNET TIMING MARK OPTION 
[RFC 858 | TELNET SUPPRESS GO AHEAD OPTION 


RFC 857 TELNET ECHO OPTION 
RFC 856 


TELNET BINARY TRANSMISSION 
[RFC 855 


TELNET OPTION SPECIFICATION 
[RFC 854 


TELNET PROTOCOL SPECIFICATION 

RFC 827 EXTERIOR GATEWAY PROTOCOL 
(EGP) 

RFC 826 An Ethernet Address Resolution 
Protocol (ARP) 

RFC 815 |1P DATAGRAM REASSEMBLY 
ALGORITHMS 

RFC 813 WINDOW AND ACKNOWLEDGMENT 
STRATEGY IN TCP 


MIL STD 1782 


RFC 793° 793 MIL MILSTD1778 1778 Transmission [Transmission Control Protocol (TCP) Protocol (TCP) 
RFC 792 pa sp 1778 __Vransm renenesion Control Protoce! (Tce) | Message Protocol 
(ICMP) 
IRFC791 791 MIL STD 1777 Internetwork Protocol ( 
RFC 783 Trivial File Transfer ee (TFTP 
Version 2) 
RFC 779 Telnet Send-Location Option 


RFC 768 User Datagram Protocol (UDP) 
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Appendix D. Common Cable Types and Pinouts 


This appendix provides the following pinout information: 


Console Port Pinouts (RJ -45) 

Auxiliary Port Pinouts (RJ-45) 

EIA-530 DTE Cable Pinout (DB-60 to DB-25) 
EIA/TIA-232 DTE Cable Pinout (DB-60 to DB-25) 
EIA/TIA-232 DCE Cable Pinout (DB-60 to DB-25) 
EIA/TIA-449 DTE Cable Pinout (DB-60 to DB-37) 
EIA/TIA-449 DCE Cable Pinout (DB-60 to DB-37) 
V.35 DTE Cable Pinout (DB-60 to 34-Pin) 

V.35 DCE Cable Pinout (DB-60 to 34-Pin) 

X.21 DTE Cable Pinout (DB-60 to DB-15) 

X.21 DCE Cable Pinout (DB-60 to DB-15) 
Ethernet (AUI) Cable Pinout (DB-15) 

Token Ring Port Pinout (DB-9) 

Asynchronous Breakout Cable Pinout (8-Pin RJ -45) 
Asynchronous- Line Cable Pinout (68-Pin SCSI 
Pinouts for the RJ-45-to-DB-25 Adapters 
Asynchronous Device Cabling Options 
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Console and Auxiliary Port Signals and Pinouts 


The console port is configured as data communications equipment (DCE), and the auxiliary 
port is configured as data terminal equipment (DTE). The console and auxiliary ports both 
use RJ-45 connectors. R]-45-to-DB-25 adapters are available for connection to modems and 
other external communications equipment. Both ports are configured as asynchronous serial 
ports. 


Table D-1 shows the pinouts for the console port and Table D-2 shows the pinouts for the 
auxiliary port. 


NOTE 


Table D-17 show the pinouts for the adapters. 


Table D-1. Console Port Pinouts (RJ -45) 


Console Port (DTE) 


Pin! [Signal f nput/ Output 


HK 


DTR——~S«iutut— SSCS 
SoD Outpt 


6 RxD [Input 
7 DSR [Input 


[1] Any pin not referenced is not connected. 


Table D-2. Auxiliary Port Pinouts (RJ -45) 


| Auxiliary Port (DTE) 


Pi ntl [Signal Input/ Output 

es Output ss—SSCS 
a; 1 
3B TxD (Output 
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[1] Any pin not referenced is not connected. 
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Serial Cable Assemblies and Pinouts 


The following illustrations and tables provide assembly drawings and pinouts for the ElA-530 
DCE, and EIA/TIA-232, ElA/TIA-449, V.35, and X.21 DTE and DCE cables. 


EIA-530 
Figure D-1 shows the EIA-530 serial cable assembly, and Table D-3 lists the pinouts. 


Figure D-1. EIA-530 Serial Cable Assembly 


J1-46 
W145 
1 a 25-pin connector J2-25 
wo) 
1-1 iy 
“i - J2-1 
J1-30 — Connectors are not to scale 
J1-31 
J1-60 


Arrows indicate signal direction: —* indicates DTE to DCE, and *™ indicates DCE to DTE. 


Table D-3. EI A-530 DTE Cable Pinout (DB-60 to DB-25) 


Signal 25 Pin Signal Direction DTE DcE!2! 
TxD/ RxD+ | J2-2 | BA(A), TxD+ ==} 


DSR/DTR+ J 2-6 CC(A), DSR+ — 
DSR/DTR- J2-22 |CC(B), DSR- — 
Shield_GND |J2-1 Shield Shorted 
MODE_2 - - 
GND - - Shorted 
MODE_1 - - 
DCD/DCD+  |J2-8 CF(A), DCD+ — 
DCD/DCD- J2-10 |CF(B), DCD- — 
J1-24 TxC/RxC+ J2-15 |DB(A), TxC+ — 
J 1-23 TxC/RxC- J2-12 |DB(B), TxC- = 
J 1- 1-260 RxC/TxCE+ {|J2-17 |DD(A), RxC+ i 
— 25 a : J 2-9 DD( ae RxC- IDD(B), RxC- fe 
J1-44 LL/DCD 2-18 Ea 
J 1-45 [Circuit_GND J 2-7 a GND }- 
))1- 7 DTR/DSR+ J2-20 |CD(A), DTR+ |— 
1-8 |DTR/DSR- = J2-23_|CD(B), DTR- |= 
J1-13 TXCE/TxXxC+ |J2-24 |DA(A), TXCE+ | — 


[1] Any pin not referenced is not connected. 


[2] The EIA-530 interface cannot be operated in DCE mode. A DCE cable is not 


available for the ElA-530 interface. 


EIA/TIA-232 


Figure D-2 shows the EIA/TIA-232 cable assembly; Table D-4 lists the DTE pinout; and Table 


D-5 lists the DCE pinout. Arrows indicate signal direction: 


*— indicates DCE to DTE. 


— 


indicates DTE to DCE, and 


Figure D-2. EI A/ TIA-232 Cable Assembly 
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- 60-pin connector oo 


Connectors are nol to scale 


Ji-1 - 
J1-30 
J1-31 
J1-60 


Table D-4. EI A/ TIA-232 DTE Cable Pinout (DB-60 to DB-25) 
60 Pin 


[1] Signal Description Direction 


J 1-50 Meee 6) Shorting group - 
J 1-51 IGN Shorting group 


J 1-52 OBE DCE |Shorting group - 

1-46 Shield GND [Single - a 
J 1-41 TxD/RxD Twisted pair no. 5 J 2-2 TxD 
Shield ————— a 
pee RxD/TxD Twisted pair no. 9 ——_s 3 

J 1-42 RIS/CTS Twisted pair no. 4 J 2-4 TS 
eee ewe a 7 


CTS/RTS Twisted pair no. 10 |—+ J2-5 | J2-5 | 


: sri 


DSR/DTR Twisted pair no. 11 |= J 2-6 
Shield 
I 45 cre GND Twisted pair no. 1 2-7 = 


iS Shield - | - Is Shield 
J 1-33 DCD/LL Twisted pair no. 12 \j— J 2-8 
Shield - - Shield - 
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ie 37 TxC/NIL Twisted pair no. 8 J— a TxC 


i 38 RXC/TXCE Twisted pair no. 7 p= > 17 |RxC 


Shield FP Sit 


) 1- 44 LL/DcD Twisted pair no. 2 E |) 2- 18 LTST 
iS Shield - | |- 5 Shield - 


J 1- 43 DTR/DSR Twisted pair no. 3 E | 2- 20 DTR 
iS Shield - - IS Shield - | 


j 1-39 TxCE/TxC posed porno. 6 pair no. 6 = j 2-24 TxCE 
iS Shield - -  —sfs Shield - 


[1] Any pin not referenced is not connected. 


Table D-5. EIA/ TIA-232 DCE Cable Pinout (DB-60 to DB-25) 


ie 1-46 Shield GND Single |- ) 2-1 ene GND 
j 1-36 IRxD/TxD Twisted pair no. 9 \— |) 2- Z TxD 


is Shield |- | - 5 Shield - 
1-41 TxD/RxD Twisted pairno. 5 |= J2-3 RxD 


Shield - | - Shield - 
J 1-35 CTS/RITS Twisted pair no. 10 \— 2-4 RTS 


Shield - | - Shield - 
j 1-42 IRTS/CTS Twisted pair no. 4 
Shi - 


Shield - - Shield |- 
J 1-40 NIL/RxC Twisted pair no. 6 J2-17 |RxC 


Shield 7 me 
J 1-33 DCD/LL Twisted pair no. 12 | J2-18 |LTST 
Shield | | ro — pao : ee — 
J 1-34 J1-34 — [DSR/DTR Twisted pair no. 11 | J2-20 |DTR 


Shield - - Shield 


J 1-38 RxC/TxCE  /Twisted pair no. 8 J 2-24 a 
Shield |- - Shield - 


[1] Any pin not referenced is not connected. 


EIA/TIA-449 


Figure D-3 shows the EIA/TIA-449 cable assembly; Table D-6 lists the DTE pinout; Table D-7 


lists the DCE pinout. Arrows indicate signal direction: —* indicates DTE to DCE, and *~ 
indicates DCE to DTE. 


Figure D-3. El A/ TIA-449 Cable Assembly 


146 

t=45 

1-16 di2-14 
1-15 he SF 


Prageereagersey 


a 


Ji-7 — J2-20 
" * Connectors are not to scale J2-1 
J|= 

1-60 


Table D-6. EI A/ TIA-449 DTE Cable Pinout (DB-60 to DB-37) 


oon 60 a" | | rn Sar 
Signal Description Direction Signal 
9 


J 1-4 IMODE_ I. is horting group |- 


rd 


J1-48 GND Shorting group - : E 


J1-51 GND Shorting group - : , 
laoe IMODE_DCE Shorting group |- : 2 


: | | | Shield 

J 1-46 Shield _ GND |Single J 2-1 GND 
TxD/RxD+ — /Twisted pair no. 6 J} 2-4 SD+ 
TxXD/RxD- J2-22 |SD- 


J 1-24 TxC/RxC+ Twisted pair no. 9 | J 2-5 ST+ 


J 1-23 TXC/RxC- 


J 1-28 IRxD/TxD+ 


[1227 RxD/TxD- 


Twisted pair no. 


— J 2-24 RD- 


j 1-9 RTS/CTS+ Twisted pairno.5 |—+ J 2-7 RS+ 
J 1-10 IRTS/CTS- I> J 2-25 IRS- 
J 1-26 RxC/TxCE+ /Twisted pair no. 10 | J 2-8 RT+ 
J1-25 RxC/TXxCE- — J2-26 |RT- 


J1-1 CTS/RTS+ Twisted pairno. 1 | J 2-9 CS+ 


J 1-2 CTS/RTS- _ J 2-27 Ics- 


y1-44 Lt/DcD Twisted pair no. 12 |—4 J2-10 |LL 


J1-45 Circuit_ GND - J 2-37 ISC 
J 1-3 DSR/DTR+ _ /|Twisted pairno. 2) | J2-11 |DM+ 
J1-4 DSR/DTR- J2-29 |DM- 


J 1-7 DTR/DSR+ 
J1-8 DTR/DSR- 


J1-5 DCD/DCD+ _ /Twisted pair no. 


Twisted pair no. 


TXCE/TxXC+ 
TXCE/TxC- | Twisted pair no. 7 


1-15 [Circuit_GND Twisted pair no. 9 - 2-19 ISG 
ja-16|CircuitGnd | SSE S~«* 2-20 RC 


[1] Any pin not referenced is not connected. 


Table D-7. E1A/ TIA-449 DCE Cable Pinout (DB-60 to DB-37) 
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60 Pin 


(1] Signal Description 
J 1-49 poe a Shorting group 
J 1-48 IGN Shorting group 
1 46 nei GND |Single 


i 


J 1-28 RxD/TxD+ — /|Twisted pair no. 
J 1-27 RxD/TxD- 


J 1-13 TxCE/TxC+ Twisted pair no. 
j 1-14 TxCE/TxC- 
J1-11 TxD/RxD+ — /Twisted pair no. 
) 1-12 TXD/RxD- 
J1-1 CTs/RIis+ 
j1-2 CTs/RITS- 
J 1-24 TxC/RxC-+ Twisted pair no. 
J 1-23 TxC/RxC- 
J 1-9 RTS/CTS+ —_|Twisted pair no. 5 


J 1-10 RTS/CTS- 2 2-27 |CS- 

J 1-29 NIL/LL Twisted pair no. 12 |—+ J2-10 jLL 

J 1-30 Circuit_GND - J2-37 |SC 

DTR/DSR- J2-29 |DM- 

DSR/DTR+ __ |Twisted pair no. 2 J2-12 |TR+ 

DSR/DTR- J2-30 |TR- 
DCD/DCD+ | [DcD/DcD+ [Twisted pair no. 3 = 2-13 RRt 


DCD/DCD- J 2-31 — 
RxC/TxCE+ /Twisted pair no. 10 = J 2-17 


Twisted pair no. 


J 1-25 RxC/TXCE- J2-35 /TT- 
J 1-15 Circuit_GND |Twisted pairno. 8 {|_ J2-19 |SG 
J 1-16 Circuit_ GND L J2-20 IRC 


[1] Any pin not referenced is not connected. 
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Figure D-4 shows the V.35 cable assembly; Table D-8 lists the DTE pinout; Table D-9 lists the 


DCE pinout. Arrows indicate signal direction: “* indicates DTE to DCE, and *™ indicates 
DCE to DTE. 


Figure D-4. V.35 Cable Assembly 


J1-46 ) 
J1-45 ——,\ 
J1-16 
J7-15 


Py a | 
11-30 Connectors are nol to scale 
1-31 
1-60 


Table D-8. V.35 DTE Cable Pinout (DB-60 to 34-Pin) 


oo 60 oo | | — E Ea 
Signal Description Direction Pin Signal 


J 1-49 MODE_1 Shorting group 


1-48 GND Shorting greup group 
J 1- 1-50 MODE_0O [Shorting group group —— 
$a 1-51 IGND Shorting group 


J 1-52 MODE_DCE_ {Shorting group 


J 1-53 TXC/NIL Shorting group 
J 1-54 RxC_TxCE Shorting group 


IS Shield - | Shield - 
) 1-42 IRTS/CTS Twisted pair no. 9 J 2- C  |RTS 
is Shield |- | = Shield - 
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ie 35 Gite Twisted pair no. 8 l— 2. D  |CTS 


7 34 DSR/DTR Twisted pair no. 7 = J 2- E DSR 
ES 33 IDCD/LL Twisted pair no. 6 E 2. F ee 


ps 43 DTR/DSR Twisted pair no. 10 S 2-4 DTR 


; 1-44 lupeb Twisted pair no. 11 EF E K re 
iS Shield - | - 5 Shield - 


TxD/RxD+  |Twisted pair no. 1 |— 2-P SD+ 
TxD/RxD- —+ 2-S___|SD- 


J 1-28 IRxD/TxD+ Twisted pair no. 5 2-R RD+ 

J1- 1-27. |RxD/TxD- fo RxD/TxD- pear pore: [le Tea T IRD- 

) 1-20 TxCE/TxC+ |Twisted pair no. 2 U |SCTE+ 
1-19 ee fae J2-W W J2-w  |SCTE- 
J 1-26 RxC/TxCE+ J1-26 — |RxC/TxCE+ Twisted pair no. 4 _ pair no. 4 ya pace aT fe ) 2- V |SCR+ 


) 1-25 IRXC/TXCE- | 2-X ISCR- 
1-24 TxC/RxC+ Twisted pair no. 3 J 2-Y IScT+ 


 1- 25 TxC/RxC- | = J 2-AA SCT- 


[1] Any pin not referenced is not connected. 


Table D-9. V.35 DCE Cable Pinout (DB-60 to 34-Pin) 


ae Pin = 
Signal Description 


+: 49 a 1 Shorting group 
J 1-48 Shorting group 
J 1-50 NODE 0 Shorting group 
J1-51 GND Shorting group String top — 

J 1-53 TXC/NIL [Shorting group group 

J 1-54 IRXC_ TXCE Shorting group - — - 


J1-55 RxD/TxD Shorting group -F  - Ff 
1-56 |GND [Shorting group ee ae 
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J 1-46 Shield _GND /|Single 2-A 


yu 45 re. GND Twisted pair no. 12 |- 


tt 


Shield | J 
J1-35 CTS/RTS a rn pairno. 8 | 2-C 
Shield - | - Shield - 
J 1-42 RiS/CIs Twisted pairno.9 |— 2-D 


J 1-43 DTR/DSR Twisted pair no. 10 E J 2- E 
iS Shield - | - shiek - 


) 1- 44 LL/DcD Twisted pair no. 11 E  2-F RLSD 
iS Shield - | - ehiel - 


1- 34 DSR/DTR Twisted pair no. 7 l— 2-H DTR 


iS Shield - | - shel - 
J 1-33 DCD/LL Twisted pair no. 6 l— J 2-K LT 
iS Shield - | oe ehiel —<— 


J 1-28 RxD/TxD+ —_|Twisted pair no. 5 

a RxD/TxD- =a ee S a= 
J1-18 TxD/RxD+ {Twisted pair no. 1 2-R 
1-17 frxp/rxD- fs 1-17 frxp/rxD- fs TXD/RxD- RD- 


J 1-26 RxC/TxCE+ |Twisted pair no. 4 a U  |SCTE+ 
J1-25 RxC/TxCE- J2-w | W_ |SCTE- 


J 1-22 INIL/RxC+ Twisted pair no. 3 = a V ISCR+ 


J1-21 NIL/RxC- 2-X  |SCR- 
J 1-20 TxCE/TxC+ |Twisted pair no. 2 J2-Y | Y |{SCT+ 
j 1-19 TxCE/TxC- | ee AA scT- 


[1] Any pin not referenced is not connected. 


X.21 


Figure D-5 shows the X.21 cable assembly; Table D-10 lists the DTE pinout; Table D-11 lists 


the DCE pinout. Arrows indicate signal direction: —* indicates DTE to DCE, and *~ 
indicates DCE to DTE. 


Figure D-5. X.21 Cable Assembly 
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J1-46 
J1-45 
J1-16 
J1-45 


[- 60-pin connector (1) / 15-pin connector (J2) 
J2-8 


[D> =a 


Connectors are not to scale 


; oe Hho De De ha 7 
i . | 


Table D-10. X.21 DTE Cable Pinout (DB-60 to DB-15) 


tn 60 bi —_ _ os 
Signal Description Direction | 15 Pin Signal 


J 1-48 IGND Is horting group 


1-47 47 So 2 Shorting group 


ne 51 Shorting group 
J 1-52 OBE DCE  |Shorting group 


J 1-46 IS Shield_ GND Is ingle - 2: I s Shield GND 


(yas TxD/RxD+ one porno tag Transmit+ 
y1-12 | y1-12 | TxD/RxD- + Transmit- 
J1-9 a — Pamir Va Control+ 
J 1-10 IRTS/CTS- a. Control- 
1-28 aio — Pen et tg Receive+ 
J 1- 1-27 1-27 |RxD/TxD- Pm 2-11 |Receive- 
p crs/rrs+ ae Pane = oo Indications 


CTS/RTS- Indication- 


T/T 


Twisted pair no. 


1-26 RxC/TXCE+ |. 


J 2-6 Timing+ 
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J 1- y1-25 | 1-25 |RxC/TxCe- | See See Timing- 


yi-as —— GND peers | es 6" 


Shield - fs hgield - 


[1] Any pin not referenced is not connected. 


Table D-11. X.21 DCE Cable Pinout (DB-60 to DB-15) 


Description 


GND Shorting group 


J 1-47 IMODE_ Z Shorting group 


J 1-46 Shield _GND_ |Single 


1-28 IRxD/TxD+ Twisted pair no. 6 | 
[peers RxD/TxD- 
| 1-1 ICTS/RTS+ Twisted pair no. 1 | = 
j 1-2 CTS/RTS- | 

J 1-11 TxD/RxD+ Twisted pair no. 3 Iz. 2-4 Receive+ 

J 1-12 TxD/RxD- | — J2-11 |Receive- 
J1-9 IRTS/CTS+ Twisted pair no. 2 |—+ : 2-5 ae 


J 1-10 RTS/CTS- J 2-12 2-12 |Indication- | 


J 1-24 TxC/RxC+ Twisted pair no. 4 |—+ p21? nsiaton- 6 |Timing+ 
J 1-23 TxC/RxC- | + J2-13 |Timing- 
J1-15 Control_GND /|Twisted pair no. 5 pena 


Shield - Shield |- 


[1] Any pin not referenced is not connected. 
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Ethernet Cable Assembly and Pinout 
Figure D-6 shows an Ethernet (AUI) cable assembly, and Table D-12 lists an AUI cable pinout. 


Figure D-6. Ethernet (AUI) Cable Assembly 


J1-15 
J1-8 


Table D-12. Ethernet (AUI) Cable Pinout (DB-15) 


| Ethernet Circuit Circuit p 0  Signah 


oe —— A = Out Circuit A 
10 DO-B Data Out Circuit B 
j11 [DO- S [Data Out Circuit Shield 
[5 [DI- A [Data In Circuit A 
DI-B Data In Circuit B 
q a S ae In Circuit Shield 
2  — {a- A [Control In Circuit A 


CI-B Control In Circuit B 
CI-S 


Control In Circuit Shield 


é vc Voltage Common 

13 VP Voltage Plus 

14 vs Voltage Shield (L25 and M25) 
‘Shell IP G [Protective Ground 


[1] Any pin not referenced is not connected. 
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Token Ring Pinout 


Table D-13 lists the pinout for the Token Ring interface port. 


Table D-13. Token Ring Port Pinout (DB-9 


9 — Signal 
_—— 
svt 
a 
Receive 


9 Transmit 


; 


[1] pins 2, 4, 7, and 8 are ground 


[2] 600 mA maximum 
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Asynchronous Serial Ports 


Figure D-7 shows the RJ-45 breakout cable with pinouts for the 68-pin SCSI port and the RJ - 
45 serial port. Table D-14 contains the pinout for the RJ-45 end, and Table D-15 contains the 
pinout for the 68-pin SCSI type connector. 


Figure D-7. Asynchronous Serial Interface Breakout Cable Assembly 


Pin 68 


, SCSI 68-pin connector 
Pin 34 


ai 


err SaGCMISSEELIIGGckIggeeE 
PEGE REED TERE aE EY 
EET tiiet ett iaee tiie Ltd 


rary 
re 


Bhs 


i 


Pin 1 
Pin 35 


Fi-45 to OB-25 adapter 


Console ees 


Table D-14. Asynchronous Breakout Cable Pinout (8-Pin RJ-45) 


| 8 Pin RJ) -45 Signal | Direction 


Cis 


EE 
DSR/DCD |— 
Se 


TXD/GND - 


TXD _ 
—+ 


i 
2 
3 
4 RXD/GND FO 
5 
6 
7 
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NOTE 


RTS — 


The Asynchronous breakout cable is equivalent to a console or auxiliary port 
with a roll-over RJ-45 cable attached. See Table D-17 for asynchronous device 


connection options. 


Table D-15. Asynchronous-Line Cable Pinout (68-Pin SCSI ) 


RJ -45 Plug 


NO} F} CO} NI} Oy} OT) BY] WW] NI] FY] CO] N| &} OO] BW) NI F |] CO] NN} OD] OT] BB] WI) Nir 


Pin 


Signal 68-Pin SCSI (J 1) 


CTs 39 
DSR [5 
RXD 36 
RXD GND 4 
[TXD GND [37 
TXD [3 


DTR 36 
RTS 2 
CIS 43 
DSR 9 
RXD 42 
RXD GND 8 
TXD GND 41 
TXD i 
DTR 40 
RTS [6 


cis 47 
DSR Is 
RXD 46 
RXD GND [12 
TXD GND 45 
TXD 11 
DTR 44. 


RTS 10 


CTS 51 


DSR [17 


NO} Fr} CO} N| | OT} BY} WN] FR | CO] NN] ®} U1] BW] NI] FR} CO] N]} OD] OF] BI] WI] NF} CO] N| | OF] BB} W 


TXD GND 
TXD 
DTR 
RTS 
CTs 
DSR 
RXD 
RXD GND 


RXD GND 28 
TXD GND 61 
TXD 27 
DTR 60 
RTS 26 
CTS 67 
DSR 33 
B (RX ——=* 
4 RXD GND 32 
5 TXD GND [65 
6 TXD 31 
7 DTR 64 
8 RTS [30 
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RJ-45 Adapter Pinouts 


Refer to Table D-16 for a list of the pins used on the RJ-45-to-DB-25 adapters, used with an 
RJ-45 cable, to connect terminals and modems to the Cisco 2500 series access server. The 
cable you use may be a roll-over cable or a straight cable. 


A roll-over cable can be detected by comparing the two modular ends of the cable. Holding 
the cables in your hand, side-by-side, with the tab at the back, the wire connected to the pin 
on the outside of the left plug should be the same color as the pin on the outside of the right 
plug. If your cable was purchased from Cisco, pin 1 will be white on one connector, and pin 8 
will be white on the other (a roll-over cable reverses pins 1 and 8, 2 and 7, 3 and 6, and 4 
and 5). (See Figure D-8.) 


Figure D-8. Identifying a Roll-Over Cable 


Pin 1 and pin & 
should be the 
same color 


Pin 1 - 


The Cisco 2500 series access server ships with a rolled cable. Connection to a terminal or a 
modem will require an RJ]-45-to-DB-25 adapter, and possibly a DB-25-to-DB9 adapter. Refer 
to Table D-17 for the cable and adapter configurations that can be used to connect terminals 


and modems to the Cisco 2500 series access server. 


Table D-16. Pinouts for the RJ -45-to-DB-25 Adapters 
1190 


| Adapter | DTE M/ F Pins!2! | DCE M/F Pins | MMOD Pins!21 
J-45 Pins _[DB-25 Pins 


[1] The female data terminal equipment (FDTE) adapter that is available from 
Cisco is labeled "Terminal." 


[2] The MMOD adapter that is available from Cisco is labeled "Modem." 


Table D-17. Asynchronous Device Cabling Options 


| Access Server Port | RJ -45 Cable Type | DB-25 Adapter | End Device 


Console or auxiliary Rolled FoTel) Terminal 


‘Console or auxiliary Straight |FDCE Terminal 


Auxiliary or console Rolled MMop!21 


[1] The FDTE RJ-45-to-DB-25 adapter is labeled "Terminal." 
[2] The MMOD RJ -45-to-DB-25 adapter is labeled "Modem." 


[3] The asynchronous breakout cable (see Table D-15) is functionally 
equivalent to a roll-over cable. 
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comparison bits:logical OR operator 


binary: comparison bits (access lists):logical OR operator 


compatibility between HDLC versions 
HDLC: compatibility between versions 


versions of HDLC, compatibility; fields: HDLC frames; frames: HDLC: fields 


compatibility switch (RIP-2) 


compress command 


commands: compress 


compression stac command 


commands: compression stac 


compression: MPPC: enabling 


MPPC compression: enabling 


conditional default routes 


configuration BPDUs 


configuring 
floating static routes 


IGRP 


unequal-cost load balancing 2nd 3rd 4th 5th 


standard IP access lists 


VoFR 
fragmentation 
configuring: access servers 
access servers: configuring 


devices: access servers:configuring 2nd 3rd 4th 


1214 


configuring: Frame Relay 
Frame Relay: configuring 


WANs: Frame Relay: configuring 2nd 


configuring: Frame Relay switching 
switching: Frame Relay 


Frame Relay: switching; WANs: Frame Relay: switching; routers: configuring as Frame Relay switch 2nd 


3rd 4th 
configuring: Frame Relay: backbone routers 


backbone routers: Frame Relay: prestaging configuration 


prestaging: Frame Relay backbone router configuration 
configuring: Frame Relay: switches 
switches: Frame Relay: prestaging configuration 


prestaging: Frame Relay switch configuration 


configuring: HSRP 
HSRP:configuring 2nd 3rd 4th 


default gateway: HSRP configuration 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 


messages: HSRP 


configuring:|GRP 
|GRP: configuring 


routing protocols:|GRP: configuring; distance vector protocols:IGRP: configuring 2nd 


configuring: | GRP: redistribution 
redistribution: |GRP 


|GRP: redistribution; distance vector protocols:|GRP: redistribution; routing protocols: |GRP: redistribut 


2nd 
configuring:|SDN 
ISDN: configuring 
WANs:!ISDN: configuring 


configuring:|SDN: hints 
hints for ISDN configuration 


ISDN: configuring: hints; WANs:|SDN:hints for configuring 2nd 


configuring: remote access 
remote access: configuring 


modems: analog remote access configuration; analog remote access: configuring; routers: modem 


configurati 2nd 3rd 4th 5th 


configuring: VoFR: dial peers 
VoFR: dial peers: configuring 


dial peers: VoFR configuration 2nd 


configuring: VoFR:POTS peers 


VoFR: POTS peers: configuring 
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POTS peers: VoFR configuration 


configuring: VoFR: voice port verification 
VoFR: voice port verification 


verifying: VOFR voice ports 


configuring: Vol P 


VolP: configuring 


CONFREG utility: corresponding bit positions (16-bit boot register) 
16-bit boot register: CONFREG utility, corresponding bit positions 
utilities: CONFREG: corresponding bit positions (16-bit boot register) 


CONFREG utility: executing 
executing: CONFREG utility 
utilities: CONFREG: executing; ROM monitor: CONFREG utility:executing 2nd 


connectivity 
NAT 
testing 
connectors 


Voice Network Modules 


consistent metrics 
IGRP 
enforcing 
console port: pinouts 
pinouts: console port 


auxiliary port: pinouts; pinouts: auxiliary port 


convergence: !1GRP 
flash updates 
|GRP: flash updates; topology: convergence: |GRP 


converting 


analog signals to digital 2nd 


copying:|OS images from TFTP server 
images: copying from TFTP server 


Cisco 1OS software: images: copying from TFTP server 2nd 


cost 
as metric 


count to infinity 
coup message (HSRP) 


CPE (customer premises equipment) 
ISDN: CPE 
WANs:!ISDN: CPE; components: of ISDN 


CRTP (compressed RTP) 
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CS-ACELP (Conjugate Structure Algebraic Code Excited Linear Predictive) 


CSAs (compression service adapters) 


compression: CSAs (compression service adapters) 


cut-through switching 
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D4 framing format 


ESF (Extended Superframe Format) 


data rate metrics 
metrics: data rate 


Frame Relay: data rate metrics; WANs: Frame Relay: data rate metrics 


DCE devices 
devices: DCE 
DDR 


advanced DDR with dialer profiles 


legacy DDR 

DDR (dial-on-demand routing) 
routing: DDR 

DDR: backup interfaces: configuring 
configuring: DDR: backup interfaces 


backup interfaces: DDR configuration; |SDN:DDR: backup interfaces 2nd 3rd 4th 


DDR: CHAP: configuring 
configuring: DDR: CHAP 
authentication: CHAP: DDR configuration; |SDN:DDR: CHAP configuration 


authentication: CHAP: DDR configuration; |SDN: DDR: CHAP configuration; alternate chap host names: 


DDR conf 2nd 
DDR: CHAP: unidirectional authentication 
configuring: DDR: CHAP 
authentication: CHAP: unidirectional authentication; |SDN:DDR: CHAP configuration; unidirectional CHAP 


au 


DDR: configuring on asynchronous interface 


remote access: DDR: configuring on asynchronous interface 2nd 3rd 4th 5th 
DDR: dialer watch: configuring 
configuring: DDR: dialer watch 


dialer watche: DDR configuration;|SDN:DDR: dialer watch 2nd 3rd 


DDR: floating static routes: configuring 
configuring: DDR: floating static routes 


floating static routes: DDR configuration;!|SDN:DDR: floating static routes 2nd 3rd 


DDR:!ISDN call screening: configuring 
configuring: DDR: call screening 


|SDN: DDR: call screening; call screening:|SDN configuration 


DDR:!ISDN callback: configuring 
configuring: DDR: callback 
ISDN: DDR: callback; callback:|ISDN configuration 2nd 3rd 4th 5th 
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DDR:LQM: configuring 
configuring: DDR: _LQM 
ISDN: DDR:LQM configuration; LQM: configuring; LQRs (Link Quality Reports) 2nd 


DDR:OSFP demand circuits: configuring 
configuring: DDR: OSPF demand circuits 
OSPF demand circuits: DDR configuration;|SDN:DDR:OSPF demand circuits 2nd 3rd 4th 


DDR: PAP: configuring 
configuring: DDR: PAP 
authentication: PAP: DDR configuration; |SDN:DDR:PAP configuration 2nd 3rd 


DDR: PPP Multilink: configuring 
configuring: DDR: PPP Multilink 
ISDN:DDR: PPP Multilink; PPP Multilink:|SDN configuration 2nd 3rd 4th 5th 


DE (discard eligible) bit 


debug commands:!SDN cause code fields 
ISDN:debug command cause code fields 


commands: debug:|SDN cause code fields; cause code fields (ISDN debug command) 


debug dialer command 


commands: debug dialer 2nd 3rd 4th 


debug disw core command 


commands: debug dlsw core 


debug disw reachability command 


commands: debug dlisw reachability 


debug eigrp packets command 


commands: debug eigrp packets 2nd 


debug frame-relay command: evaluating output 
evaluating: debug frame-relay command output 


output: debug frame-relay command:evaluating 2nd 


debug frame-relay Imi command 


commands: debug frame-relay Imi 


displaying: LMI exchanges; mismatched LMIs: displaying 


debug ip igrp transactions command 
commands: debug ip igrp 


routing updates:!1GRP: displaying information; displaying:|GRP routing update information 


commands: debug ip igrp transactions 


debug ip nat command 


commands: debug ip nat 2nd 


debug ip ospf adj command 


commands: debug ip ospf adj 2nd 


debug ip ospf events command 
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commands: debug ip ospf events 


debug ip rip command 


commands: debug ip rip 2nd 


debug isdn command 
progress description field values 


commands: debug isdn: progress description field values; progress description field values (debug isdn 


debug isdn commands: bearer capability values 
commands: debug isdn: bearer capability values 


bearer capability values: debug isdn command 


debug isdn events command 


commands: debug isdn events 


debug isdn g.921 command 


commands: debug isdn q.921 


debug ntp events command 


commands: debug ntp events 


debug ntp select command 


commands: debug ntp select 


debug ppp authentication command 


commands: debug ppp authentication 2nd 3rd 


debug ppp negotiation command 


commands: debug ppp negotiation 2nd 


debug serial interface command 


commands: debug serial interface 2nd 


debug standby command 


commands: debug standby 


default gateway 


HSRP configuration 2nd 3rd 


delay 
as metric 
|GRP metric 
delay metric (EIGRP) 
EIGRP: delay metric 
metrics: EIGRP: delay; hybrid protocols: E1GRP: delay metric; routing protocols: EIGRP:delay metric 2nd 


delay start signaling 
analog telephony: trunks: Supervory signaling: delay start 


trunks: Supervisory signaling: delay start; tie trunks: supervisory signaling: delay start; supervisory s 


DELETED status (PVCs) 2nd 


demand circuits 
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OSPF:demand circuits 


link-state routing protocols: OSPF: demand circuits 


demand circuits: OSPF: configuring 
configuring: OSPF: demand circuits 


OSPF: demand circuits: configuring; link-state protocols: OSPF:demand circuit configuration; routing 


prot 2nd 
deploying 
PPP 
design considerations: OSPF 


OSPF: design considerations 2nd 


devices 
access servers 


configuring 2nd 3rd 4th 


bridges 2nd 


route generators 


devices: access servers 
access servers 


router: configuring with access servers 


devices: DCE 
DCE devices 
devices: gaining privlileged access 


privileged access: gaining to devices 


devices: routers: Cisco 1750 
Cisco1750 routers 


routers: Cisco 1750; voice- capable routers: Cisco 1750 


devices: routers: Cisco 2600 
Cisco 2600 routers 


routers: Cisco 2600; voice-capable routers: Cisco 2600 


devices: routers: Cisco 3600 
Cisco 3600 routers 


routers: Cisco 3600; voice- capable routers: Cisco 3600 


devices: routers: Cisco 7200 
Cisco 7200 routers 


routers: Cisco 7200; voice-capable routers: Cisco 7200 


devices: routers: Cisco MC3810 
Cisco MC3810 routers 


routers: Cisco MC3810; voice-capable routers: Cisco MC3810 


dial peers 


configuring 
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dialer 


dialer enable-timeout command 


commands: dialer enable-timeout 


dialer fast-idle command 


commands: dialer fast-idle 


dialer idle-timeout command 


commands: dialer idle-timeout 


dialer in-band command 


commands: dialer-in- band 


dialer interface:|P addressing configuration 


configuring: dialer interfaces:|P addressing 


dialer load-threshold command 


commands: dialer load-threshold 2nd 


dialer string command 


commands: dialer string 


dialer watch command 


commands: dialer watch 


dialer-group command 


commands: dialer- group 


DID (direct inward dial) trunks 
trunks: DID 


analog telephony:trunks: DID 


digital signaling 
signaling: digital 


Dijkstra algorithm 


direct encapsulation (SRB) 
configuring 
Disabled STP state 
STP: Disabled state 
Ethernet: STP: Disabled state; |EEE 802.1d (STP):Disabled state; loop prevention: STP: Disabled state 


disabling 
split horizon 
disabling: split horizon on IGRP interfaces 


interfaces:|GRP: split horizon, disabling 


displaying 
SNTP status 
displaying: access lists 
acces lists: displaying 


viewing: access lists 
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displaying: OSPF adjacency status 


viewing: OSPF adjacency status 


distance command 


commands: distance 


distance vector protocols 


hybrid protocols 


distance vector routing protocols: versus link-state routing protocols 


link-state routing protocols: versus distance vector routing protocols 


distance-vector routing protocols: routing loops: preventing 
preventing: routing loops 


routing loops: preventing 


distribute lists 
distribute-list command 
commands: distribute-list 2nd 3rd 


DLCIs 


WANs: Frame Relay: DLCIs 
Frame RElay: DLCls 


DLCls (data-link connection identifiers) 


DLSw+ 


transporting nonroutable protocols: DLSw+ 


nonroutable protocols, transporting: DLSw+ 


DLSw+:address format 
transporting nonroutable protocols: DLSw+: address format 


nonroutable protocols, transporting: DLSw+: address format; address formats: DLSw+ 


DLSw+: configuring 
transporting nonroutable protocols: DLSw+: configuring 


nonroutable protocols, transporting: DLSw+: configuring; configuring: DLSw+ 2nd 3rd 4th 5th 


DLSw+:example configuration 
transporting nonroutable protocols: DLSw+: example configuration 
nonroutable protocols, transporting: DLSw+: example configuration; example configuration: DLSw+ 


2nd 3rd 


DLSw+: features 
transporting nonroutable protocols: DLSw+: features 


nonroutable protocols, transporting: DLSw+: features 


DLSw+:technical overview 
transporting nonroutable protocols: DLSw+: capabilities exchange 


nonroutable protocols, transporting: DLSw+: capabilities exchange; capabilities exchange: DLSw+ 2nd 


transporting nonroutable protocols: DLSw+: circuit establishment 


nonroutable protocols, transporting: DLSw+: circuit establishment; circuit establishment: DLSw+ 
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transporting nonroutable protocols: DLSw+: flow control 


nonroutable protocols, transporting: DLSw+: flow control; flow control: DLSw+; traffic: DLSw+: flow 


control 
transporting nonroutable protocols: DLSw+: technical overview 


nonroutable protocols, transporting: DLSw+: technical overview; technical overview:DLSw+ 2nd 3rd 


DLSw:NAT translation, configuring 
configuring: NAT: DLSw 
NAT: DLSw translation:configuring 2nd 3rd 4th 


DOD (direct outward dial) trunks 
trunks: DOD 
analog telephony: trunks: DOD 


donOtcarebit [donOt care bit] 


Down neighbor state (OSPF) 


downloading: Cisco |OS software 
software: Cisco 10S: downloading 


Cisco |OS software: downloading 


Doyle, Jeff 2nd 


DRAM: lab requirements 


FLASH memory: lab requirements 


DS-0 channels 
DSi. 
DTMF signaling 
address signaling: DTMF 
signaling: address signaling: DTMF 


duplex Ethernet mode 


during-login argument (autoselect command) 


dynamic access lists: configuring 
configuring: dynamic access lists 


access lists:dynamic:configuring 2nd 3rd 4th 


dynamic address mapping: Frame Relay configuration 
configuring: Frame Relay: dynamic address mapping 


Frame Relay: dynamic address mapping configuration 2nd 


dynamic peers (DLSw+) 


configuring 2nd 
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E&M signaling 
Voice Network Module 


El 


echo 
listener echo 
talker echo 
echo suppression 
echo cancellation 


canceling echo;suppressing echo 2nd 


EIA-530 serial cable: pinouts 
pinouts: EIA-530 


EIA/TIA-232 serial cable: pinouts 


pinouts: EIA-232 serial cable 


EIA/TIA-449 serial cable: pinouts 
pinouts: EIA-449 serial cable 
EIGRP 
redistributing into RIP 2nd 3rd 


eigrp log-neighbor changes command 


commands: eigrp log-neighbor changes 


eigrp no auto-summary command 


commands: eigrp no auto-summary 


EI GRP: configuring 
configuring: ElGRP 
hybrid protocols: ElGRP: configuring; routing protocols: EIGRP:configuring 2nd 3rd 
EI GRP: default routing 


default routing: EIGRP 
hybrid protocols: ElGRP: default routing; routing protocols:EIGRP:default routing 2nd 3rd 


EI GRP: DUAL 
DUAL (Diffusing Update Algorithm) 
hybrid protocols: EIGRP: DUAL; routing protocols: EIGRP: DUAL 2nd 


EI GRP: equal-cost load balancing 
equal-cost load balancing 


traffic: EIGRP: equal-cost load balancing; hybrid protocols: E1GRP:equal-cost load balancing; routing pro 


2nd 
EIGRP: neighbor establishment 
neighbor establishment: EIGRP 
hybrid protocols: El1GRP: neighbor establishment; routing protocols: E1GRP: neighbor establishment; 
establi 2nd 3rd 
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EIGRP: neighbors 
neighbors: ElGRP 
hybrid protocols: ElGRP: neighbors; routing protocols: ElGRP: neighbors 


EIGRP: packet types 
packets: EIGRP 
Hello packets: El1GRP; ACKs: El GRP; updates: EIGRP; queries: EIGRP; replies:EIGRP 2nd 


EI GRP: protocol-dependent modules 
protocol-dependent modules 


hybrid protocols: ElGRP: protocol-dependent modules; routing protocols: El GRP: protocol-dependent 


modules 
EIGRP: redistribution 
EIGRP: redistribution 
hybrid protocols: ElGRP: redistribution; routing protocols: EIGRP:redistribution 2nd 


EIGRP: RTP 
RTP (Reliable Transport Protocol) 
hybrid protocols: E1GRP:RTP; routing protocols:EIGRP:RTP 2nd 


EIGRP:stub routing 
stub routing (EIGRP) 
hybrid protocols: EIGRP: stub routing; routing protocols: EIGRP:stub routing; configuring: EIGRP:stub 


rout 2nd 3rd 4th 


EIGRP: summarization: autosummarization 
summarization: El GRP: autosummarization 


hybrid protocols: E1GRP: autosummarization; routing protocols: ElGRP: autosummarization; 


autosummarization 2nd 3rd 4th 


EIGRP: summarization: manual summarization 
summarization: ElGRP: manual summarization 


hybrid protocols: E1GRP: manual summarization; routing protocols: El1GRP: manual summarization; 


manual summ 2nd 


EIGRP: summarization: SIA routes 
summarization: ElGRP: SIA routes 


hybrid protocols: E1GRP: summarization; routing protocols: ElGRP: summarization; SIA routes: resolving; 


reso 2nd 
EIGRP: technical overview 
hybrid protocols: ElGRP: technical overview 


technical overview:EIGRP 2nd 


EI GRP: unequal-cost load balancing: configuring 
unequal-cost load balancing: EI GRP: configuring 


hybrid protocols: E1GRP: unequal-cost load balancing; routing protocols: EIGRP: unequal-cost load 


balanci 2nd 3rd 
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EI GRP: updates: tuning 
updates: EI GRP: tuning 
tuning: EIGRP updates 


electing: root bridges 
root bridges: election process 


STP:root bridges:election process 2nd 


election process 


OSPF DRs/BDRs 


election process (root bridges) 
root bridges: election process 


STP: root bridges: election process 


enabling 


[LMI connectivity 


enabling: LQM 
LQM: enabling 

enabling: transparent bridging 
transparent bridging: enabling 


bridging: transparent: enabling; transporting nonroutable protocols: transparent bridging: enabling; 


nonro 2nd 
encapsulation 
HDLC 


multiprotocol encapsulation 


encapsulation aal5mux voice command 


commands: encapsulation aalbmux voice 


encapsulation hdlc command 


commands: encapsulation hdlc 


encapsulation ppp command 


commands: encapsulation ppp 


ppp authentication command 


commands: encapsulation ppp; commands: ppp authentication 


encapsulation:ISL 
ISL (Inter-Switch Link) 
trunking protocols:|ISL; switched Ethernet:ISL 


error correction 


overengineered protocols 


ESI (end station identifier) 


Ethernet: cable assembly 
pinouts: AUI cables 


AUI cable assembly 
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Ethernet: CSMA/CD 
CSMA/CD 
IEEE 802.3: Ethernet: CSMA/CD; LANs: Ethernet: CSMA/CD 


Ethernet: half-duplex 
half-duplex Ethernet 
Ethernet: full- duplex; LANs: Ethernet: half- duplex; LANs: Ethernet: full- duplex 


Ethernet: history of 
history of Ethernet 
LANs: Ethernet: history of; PARC (Palo Alto Research Center):development of Ethernet; development of 


Eth 
Ethernet: operation 
LANs: Ethernet: operation 
Ethernet: MAC layer; Ethernet: LLC (Logical Link Control) layer; MAC layer; LLC (Logical Link Control) la 


Ethernet: switching 
switching: Ethernet 


[EEE 802.3: Ethernet switching; LANs: Ethernet: switching 2nd 


example configuration: SRB 
SRB: example configuration 


configuring: SRB: example; bridging: SRB: example configuration; transporting nonroutable protocols: 


SRB:ex 2nd 3rd 4th 5th 6th 


Exchange neighbor state (OSPF) 
expiration timer: RIP 


invalid timer: RIP 


explicit acknowledgments 


ExStart neighbor state (OSPF) 


extended IP access lists: configuring 
configuring: extended IP access lists 
access lists: extended | P: configuring; route filtering: extended |P access lists: configuring; filtering 2nd 


3rd 4th 5th 6th 


extended IP access lists: precedence values, setting 
access lists: extended IP: precedence values 


precedence values: configuring on extended IP access lists; configuring: extended IP access lists: prece 


extended IP access lists: Protocol field values 


access lists: extended IP: Protocol field values 2nd 


exterior routes (I|GRP) 


external Type 1 paths (OSPF) 


external Type 2 paths (OSPF) 
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feasible distance 
EIGRP: feasible distance 


metrics: El|GRP: feasible distance 


feasible successors: EIGRP 


EIGRP: feasible successors 


FECN (forward explicit congestion notification) 


Flash updates 
GRP 


floating static routes 


static routes: floating static routes 2nd 


FLP (Fast Link Pulse) 
[EEE 802.3u:FLP (Fast Link Pulse) 


Ethernet: autonegotiation; LANs: Ethernet: autonegotiation; autonegotiation 2nd 


flush timer 
LGRP 
RIP 
forcing 
RIDs 
forward delay timer (STP) 


Forwarding STP state 
STP: Forwarding state 
Ethernet: STP: Forwarding state; |EEE 802.1d (STP):Forwarding state;loop prevention: STP: Forwarding 


stat 2nd 

Frame Relay 
VoFR 

Frame Relay encapsulation (SRB) 
configuring 

Frame Relay: address mapping: configuring 
configuring: Frame Relay: address mapping 


address mapping: Frame Relay configuration; WANs: Frame Relay: address mapping configuration 2nd 


Frame Relay: address mappings: displaying 
address mappings: Frame Relay: displaying 


displaying: Frame Relay address mappings 


Frame Relay: configuring 
configuring: Frame Relay 


WANs: Frame Relay: configuring 


Frame Relay: DLSw: configuring 


configuring: Frame Relay: DLSw 
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DLSw: over Frame Relay, configuring; WANs: Frame Relay: DLSw configuration 2nd 


Frame Relay: hybrid networks: configuring 
configuring: Frame Relay: hybrid networks 


hybrid Frame Relay networks: configuring; WANs: Frame Relay: hybrid network configuration 2nd 


Frame Relay:!P RTP priority 
WANs: Frame Relay:IP RTP priority 2nd 


Frame Relay: map classes: creating 
creating: FRTS map classes 


map classes (FRTS): creating; traffic: FRTS: map classes: configuring 2nd 


Frame Relay: multipoint networks: configuring 
multipoint networks: Frame Relay configuration 
configuring: Frame Relay: multipoint networks; WANs: Frame Relay: multipoint network configuration 


2nd 3rd 4th 5th 


Frame Relay: point-to-point networks: configuring 
point-to-point networks: Frame Relay configuration 
configuring: Frame Relay: point-to-point networks; WANs: Frame Relay: point-to-point network 


configuratio 2nd 3rd 4th 5th 6th 


Frame Relay:routing protocol configuration 
configuring: Frame Relay: routing protocols 


routing protocols: configuring over Frame Relay 2nd 


Frame Relay: serial interface configuration 


serial interfaces: Frame Relay configuration 


Frame Relay: summarization: configuring 
configuring: Frame Relay: route summarization 


summarization: configuring on Frame Relay links 2nd 


Frame Relay:switch configuration 
switches: Frame Relay: configuring 


devices: switches: Frame Relay, configuring; WANs: Frame Relay: switch configuration; configuring: 


Frame Re 
Frame Relay: switching: configuring 
configuring: Frame Relay switching 


switching: Frame Relay: configuring; WANs: Frame Relay: switching configuration 2nd 3rd 4th 5th 


frame-relay interface-dlci command 


commands: frame-relay interface dlci 


frame-relay Imi-type ansi command 


commands: frame-relay Imi-type ansi 


frame-relay map command 


commands: frame-relay map 


frame-relay route command 
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commands: frame-relay route 


frame-relay voice bandwidth command 


commands: frame-relay voice bandwidth 


framework of internetwork modeling: building 
building: framework for internetwork modeling 


internetworks: modeling: building framework 


framework of internetwork modeling: building: 16-bit boot register 
building: framework for internetwork modeling: 16-bit boot register 
internetworks: modeling: building framework 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 
13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 


framing formats: T1 


T1 framing formats 


FRTS: configuring 
configuring: FRTS 
traffic: FRTS: configuring 2nd 


traffic: FRTS: configuring; WANs:Frame Relay:FRTS configuration 2nd 3rd 


FRTS:queing mechanisms: configuring 
configuring: FRTS: queuing mechanisms 


traffic: FRTS: configuring; WANs: Frame Relay:FRTS configuration; queuing mechanisms: FRTS 


configuration 
FRTS:tokens 
configuring: FRTS 
traffic: FRTS: tokens; WANs: Frame Relay: FRTS configuration; tokens 


FST encapsulation (SRB) 


configuring 
Full neighbor state (OSPF) 


full-duplex Token Ring 
half-duplex Token Ring 
FXO 


Voice Network Module 


FXS 


Voice Network Module 


1231 


[SYMBOL] [A] [B] [C] [DB] [E} [F) (G] CH) [1] [K) (L) [M] (NJ [0] [P) [Q] [RI [S) [1] (YU) [M) [W) [X] 


GBICs 

interfaces: GBICs 
Gigastack GBIC 

GBI Cs: Gigastack GBIC 


glare 
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handset 
off-hook signaling 
hash 
HDLC (High-Level Data Link Control) 


HDLC: configuring 
configuring: HDLC 
WANs: HDLC: configuring 


WANs: HDLC: configuring; encapsulation: HDLC: configuring 2nd 3rd 


HDLC: DCE-DTE connections: configuring 
configuring: HDLC: DCE-DTE connections 
connectivity: HDLC DCE-to-DTE: configuring; WANs: HDLC: configuring DCE-to-DTE connectivity 2nd 
3rd 4th 5th 
HDLC: keepalive 


keepalives: HDLC 


HDLC:serial controllers: retrieving physical layer status 
serial controllers (HDLC): retrieving physical layer status 


OSI model: physical layer: retrieving status from serial controllers 2nd 


header compression 
[PF RIP 

hello message (HSRP) 
messages: HSRP 


HSRP: messages 


hello timer (STP) 


hellos 
EIGRP 2nd 
hold-down timer:|GRP 


timers:|GRP 


|GRP: timers; distance vector protocols:|GRP: timers; routing protocols:|GRP: timers 


hold-down timer: RIP 


convergence: hold- down timer 


hop count 
host names: assigning to routers 
routers: host names, assigning 


assigning: host names to routers; devices: routers: assigning host names 


hot standby address 
HSRP: hot standby address 
HSRP 


tracking on serial interfaces 
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HSRP (Hot Standby Routing Protocol) 


HSRP: authentication: configuring 
configuring: HSRP: authentication 


security: authentication: HSRP, configuring 


HSRP: down state 
down state (HSRP) 


HSRP: virtual address 
virtual address (HSRP) 


hybrid coders 
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icanreach command 


commands:icanreach 2nd 3rd 


[EEE 802.10 trunking encapsulation 


IEEE 802.1d (Spanning Tree Protocol) 
STP (Spanning Tree Protocol) 
Perlman, Radia; Ethernet: STP; LANs: Ethernet: STP; switched Ethernet: STP 


IEEE 802.1d (Spanning Tree Protocol): operation 


STP (Spanning Tree Protocol): operation 


Ethernet: STP: operation; LANs: Ethernet: STP; switched Ethernet: STP: operation; loop prevention: STP 
2nd 
IEEE 802.3:specifications 
Ethernet: |EEE 802.3:specifications 


specifications: Ethernet 
Ethernet: specifications; LANs: Ethernet: specifications 
[EEE 802.3y (Fast Ethernet) 
Fast Ethernet 


Ethernet: Fast Ethernet 
IEEE 802.3z (Gigabit Ethernet) 
Gigabit Ethernet 


Ethernet: Gigabit Ethernet 
IEEE 802.3z (Gigabit Ethernet): 1000Base-CX 
Gigabit Ethernet: 1000Base- CX 


Ethernet: Gigabit Ethernet: 1000Base- CX; 1000Base-CX Gigabit Ethernet 
IEEE 802.3z (Gigabit Ethernet): 1000Base-LX 
Gigabit Ethernet: 1000Base-LX 


Ethernet: Gigabit Ethernet: 1000Base-LX; 1000Base-LX Gigabit Ethernet 
IEEE 802.3z (Gigabit Ethernet): 1000Base-SX 
Gigabit Ethernet: 1000Base-SX 


Ethernet: Gigabit Ethernet: 1000Base-SX; 1000Base-SX Gigabit Ethernet 
IEEE 802.3z (Gigabit Ethernet): 1000Base-T 
Gigabit Ethernet: 1000Base-T 


Ethernet: Gigabit Ethernet: 1000Base-T; 1000Base-T Gigabit Ethernet 


|IFG (interframe gap) 


|GRP: default routing 
routing protocols:!1GRP: default routing 


distance vector protocols:|GRP: default routing; default routing: |GRP; configuring: |GRP: default routing 


2n 


Qa 


|GRP: default routing: configuring 1235 


configuring: | GRP: default routing 
default routing: |GRP: configuring; distance vector routing: !|GRP: default routing; routing protocols: |GRP 


2nd 3rd 


|GRP: distribute lists: configuring 
configuring: |GRP: distribute lists 


distribute lists: |GRP: configuring; distance vector protocols:|GRP: distribute list configuration; routi 


IGRP: metric: default, setting 
setting: |GRP default metric 
default metric:|GRP, setting 


|GRP: metrics 
distance vector protocols:!GRP: metrics 


routing protocols: 1GRP: metrics; metrics: |GRP 


GRP: route types 
distance vector protocols:|GRP: route types 


routing protocols:|GRP: route types 


IGRP: routing updates: filtering 
filtering: |GRP routing updates 
routing updates: |1GRP: filtering 


IGRP: split horizon 
split horizon: 1GRP 


interfaces: split horizon 


|GRP: technical overview 
distance vector protocols:|GRP: technical overview 


routing protocols:|GRP:technical overview 2nd 3rd 


GRP: unequal-cost load balancing 
unequal-cost load balancing 


traffic: |GRP: unequal-cost load balancing; routing protocols: |GRP: unequal-cost load balancing; 


distance 2nd 3rd 4th 5th 


|GRP: unequal-cost load balancing: configuring 
configuring: |GRP: unequal-cost load balancing 
unequal-cost load balancing: configuring; traffic: unequal-cost load balancing: configuring; metrics: uneq 


2nd 


| GRP: updates: verifying 
verifying:|GRP updates 


distance vector protocols:|GRP: updates, verifying 


ILMI (Integrated Local Management Interface) 
ATM: 1 LMI 
immediate start signaling 


analog telephony: trunks: Supervory signaling: immediate start 
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trunks: supervisory signaling: immediate start; tie trunks: supervisory signaling: immediate start; super 


implicit acknowledgements 


implicit deny 
configuring: access lists: guidelines 


guidelines: for access list configuration; access lists: configuration guidelines; applying: access lists 


INACTIVE status (PVCs) 2nd 


inarp command 


commands: inarp 
INIT bit 
EIGRP:INIT bit 
hybrid protocols: EIGRP:INIT bit; routing protocols: EIGRP:INIT bit 


[nit neighbor state (OSPF) 


integrating |GRP and EIGRP 2nd 


interarea paths (OSPF) 


interesting traffic 
traffic: interesting 


ISDN: interesting traffic 


interesting traffic: defining 


defining: interesting traffic 


interface async command 


commands: interface async 


interface dialer command 


commands: interface dialer 


interfaces: applying access lists 
appying: access lists to interfaces 


access lists:applying to interfaces; packet filtering: access lists: applying to interfaces; filtering p 


interfaces: CDP, disabling 
disabling: CDP on interfaces 


CDP: disabling on interfaces 


interfaces: clock rate: configuring 
clock rate: configuring on interfaces 


serial interfaces: clock rate: configuring; configuring: clock rate on serial interfaces 


interfaces: forcing into stanby mode 
forcing interfaces into standby mode 


standby mode: forcing 


interfaces: HDLC: show interface serial command operational status output 


HDLC: interfaces: show interface command operational status output 


interfaces: |SDN: backup mode 


backup load command 
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commands: backup load;|ISDN: interfaces: backup mode 2nd 


interfaces: Token Ring: pinout 
pinouts: Token Ring interface port 


Token Ring:interface port pinout 


interior routes (IGRP) 


internal routers 


internetworks: modeling: test procedures 
modeling: internetworks: test procedures 


testing: network models 2nd 


internetworks: WANs: modeling 
modeling: WANs 


WANs: modeling: with routers in back-to-back mode; back-to-back routers: WANs, modeling; routers: 


back-to- 
modeling: WANs: with back-to-back routers 


WANs: modeling: with routers in back-to-back mode; back-to-back routers: WANs, modeling; routers: 


back-to- 2nd 3rd 


interrupting 
switch/router operations 


Abort at message 2nd 


intra-area paths (OSPF) 


invalid timer (IGRP) 


Inverse ARP 


Frame Relay address mappings 
ip classless command 


commands: ip classless 


ip domain-lookup command 


commands: ip domain-lookup 


ip name-server command 


commands: ip name-server 


ip nat inside source command 


commands: ip nat inside source 


ip nat translation dns-timeout command 


commands: ip nat translation dns-timeout 


ip nat translation finrst-timeout command 


commands: ip nat translation finrst-timeout 


ip nat translation icmp-timeout command 


commands: ip nat translation icmp-timeout 


ip nat translation port-timeout command 


commands: ip nat translation port-timeout 


1238 


ip nat translation syn-timeout command 


commands: ip nat translation syn-timeout 


ip nat translation tcp-timeout command 


commands: ip nat translation tcp-timeout 


ip nat translation timeout command 


commands: ip nat translation timeout 


ip ospf dead-interval command 


commands: ip ospf dead- interval 


ip ospf hell-interval command 


commands: ip ospf hello-interval 
IP precedence 


VolIP:IP precedence 


IP RTP header compression 


ip subnet zero command 


commands: ip subnet zero 


ISDN (Integrated Services Digital Network) 
N-ISDN (Narrowband ISDN) 
B-ISDN (Broadband ISDN);WANs:ISDN 
ISDN:B (bearer) channel 


B (bearer) channel:|SDN 
D (data) channel:|ISDN;H channel (ISDN);channels:|SDN 


ISDN: connectivity 
connectivity:|SDN 
WANs:!ISDN: connectivity 


1SDN:DDR: configuring 
configuring:|SDN:DDR 
DDR (Dial-on-Demand Routing): advanced parameters: configuring; WANs:!ISDN:DDR configuration; 
advanced pa 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 
19th 20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th 30th 
DDR (Dial-on-Demand Routing): configuring; WANs:ISDN:DDR configuration 2nd 3rd 


DDR (Dial-on-Demand Routing): dialer information: configuring; WANs:ISDN:DDR configuration; dialer 


infor 2nd 3rd 4th 5th 6th 


DDR (Dial-on-Demand Routing): interesting traffic: configuring; WANs:!SDN:DDR configuration; 


interesting 
DDR (Dial-on-Demand Routing):ISDN switch type: configuring; WANs:ISDN:DDR configuration 2nd 


ISDN:DDR: dialer profiles 
dialer profiles 
ISDN: encapsulation 


encapsulation: |SDN 
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WANs:ISDN: encapsulation 2nd 


ISDN:lab exercises 
lab exercises: ISDN 


WANs:ISDN:lab exercises 2nd 3rd 4th 5th 


ISDN:S/T interface 
S/T interface (ISDN) 
WANs:1ISDN: S/T interface; interfaces: |SDN: S/T 


ISDN: switch types 
switches:|SDN 
WANs:ISDN: switch types 

switches: ISDN 

| TU-T 

ITU:ISDN protocol categories 
ISDN: categories of 


WANs:ISDN: categories of 2nd 
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keepalives: LMI 


LMI keepalives 
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lab exercises: ATM: required equipment 
ATM: lab exercises: required equipment 


requirements: for ATM lab exercises 


lab exercises: DLSw+ 
DLSw-+:lab exercises 


configuring: DLSw+: lab exercises; transporting nonroutable protocols: DLSw+: lab exercises; 


nonroutable p 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 


lab exercises: EIGRP: configuring 
configuring: EIGRP:lab exercises 
EIGRP:lab exercises; hybrid protocols: EIGRP: lab exercises; routing protocols: EIGRP:lab exercises 2nd 


3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 


labs: hardware/software requirements 
equipment: lab requirements 


hardware: lab requirements; software: lab requirements; requirements:labs 2nd 


LANs: modeling 
modeling: LANs 


internetwork: LANs: modeling 


LANs: modeling: with Ethernet crossover cable 
modeling: LANs: with Ethernet crossover cable 


Ethernet crossover cable: modeling LANs; internetworks: LANs: modeling 2nd 


LANs: modeling: with hubs and MAUs 
modeling: LANs: with hubs and MAUs 
internetwork: LANs: modeling; hubs: LAN modeling; MAUs: LAN modeling 


LANs: modeling: with switches 
modeling: LANs: with switches 


switches: modeling LANs; internetworks: LANs: modeling 


LANs: simulating: with backbone routers 
simulating: LANs: with bacbone routers 


backbone routers: LANs, simulating 


LANs: simulating: with route generators 
simulating: LANs: with route generators 


route generator: LANs, simulating 


LANs: Token Ring: operation 
Token Ring: operation 


IEEE 802.5 (Token Ring): operation 2nd 


LANs: Token Ring: Technical overview 
Token Ring:technical overview 


technical overview: Token Ring;|EEE 802.5 (Token Ring): technical overview 2nd 
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last mile 
layers of OSI reference model 


OSI reference model: layers 


LCP (Link Control Protocol) 


LD-CELP (Low Delay Code Excited Linear Predictive) 


LDN (local directory number) 
Learning STP state 
STP: Learning state 
Ethernet: STP: Learning state; |EEE 802.1d (STP):Learning state; loop prevention: STP: Learning state 


legacy DDR 
DDR: legacy 
DDR: dialer profiles 


legacy DDR (dial-on-demand routing) 


Lempel-Ziv compression algorithm 


limiting: |GRP broadcasts on Ethernet segments 
|GRP: broadcasts: limiting on Ethernet segments 


routing protocols:!1GRP: limiting broadcasts on Ethernet segments 2nd 


link establishment phase (LCP) 


link failures: STP 
STP: link failures 


link termination phase (LCP) 


link- quality determination phase (LCP) 


link-state database 
advertisements: LSAs 


OSPF: link-state database; link-state protocols: OSPF: link-state database; routing protocols: OSPF: link-s 


link-state databases 


link-state protocols 


hybrid protocols 


link-state routing protocols 


routing protocols: link state 


routing protocols: link state: comparing to distance vector 


comparing: link-state and distance vector routing protocols 


links: HDLC: troubleshooting 
troubleshooting: HDLC links 
HDLC: links: troubleshooting; WANs: HDLC: links, troubleshooting 2nd 3rd 4th 


Listening STP state 
STP: Listening state 
Ethernet: STP: Listening state; |EEE 802.1d (STP):Listening state;loop prevention: STP: Listening state 


2nd 
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LLC2 capture entity 


LMI 
ILMI 


LMI (Local Management Interface) 


Frame Relay: LMI 
WANs: Frame Relay:LMI 2nd 3rd 


LMI autosense 
LMIs: ANSI 
ANS! LMIs 
LMIs: Cisco 
Cisco LMIs 
load 
EIGRP metric 
IGRP_ metric 
load balancing 


unequal-cost load balancing 


load-sharing groups 


Loading neighbor state (OSPF) 


local access rate 
Frame Relay:local access rate 


WANs: Frame Relay: local access rate 


lock-and-key security 


security: lock-and-key 


log adjacency-changes command 


commands: log adjacency- changes 
logging buffered command 


commands: logging buffered 


logging synchronous command 


commands: logging synchronous 


logical AND 
access lists:logical AND 


standard access lists: logical AND; filtering packets: logical AND; packet filtering: logical AND; Boolean 


logical dialer information 


dialer information configuration 2nd 


logical OR 
Boolean OR 


standard access lists: logical OR; access lists: logical OR; packet filtering: logical OR; filtering packe 2nd 


3rd 


longest match lookup 
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route tables: longest match lookup 


loopback addresses 


reverse Telnet sessions, configuring 2nd 


loopback interface: route generators, configuring 


virtual interfaces: route generators, configuring 2nd 


lossless compression algorithms 


LQM (Link Quality Monitoring) 


monitoring: PPP link quality 
quality of PPP links: monitoring; PPP: links, monitoring 2nd 


LQM: enabling on interface 


enabling: LQM on interface 


LQORs (Link Quality Reports) 


LSAs (link-state advertisements) 


advertisements: LSAs 


OSPF:LSAs; link-state protocols: OSPF: LSAs; routing protocols: OSPF:LSAs 
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manipulating 
Flash devices; 
map class configuration mode 


FRTS configuration 


map-class frame-relay vofr command 


commands: map-class frame-relay vofr command 


map-groups 
map-lists 
MAX Age timer 
transparent bridging: MAX Age timer 


bridging: transparent: MAX Age timer; Ethernet: transparent briding: MAX Age timer; nonroutable 


protocols, 


max age timer (STP) 


MaxR (maximum data rate) 


MD5 (Message Digest 5) hash generator 


memory 


lab requirements 2nd 


message 
RIP 


receive control switch 


messages 
VTP 2nd 
metrics 
EIGRP 
EIGRP: metrics; hybrid protocols:EIGRP: metrics 2nd 3rd 


|GRP 
unequal-cost load balancing, configuring 2nd 3rd 4th 5th 


metrics: ElGRP: bandwidth 
bandwidth: EIGRP metric 
EIGRP: bandwidth metric; hybrid protocols: ElIGRP: bandwidth metric 


metrics: El1GRP: CM 
CM (composite metric) 


EIGRP: CM (composite metric) 


metrics: El GRP: delay 
delay: EIGRP metric 
EIGRP: delay metric; hybrid protocols: EIGRP: delay metric 


metrics: El GRP: reliability 


reliability: E1GRP metric 
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EI GRP: reliability metric; hybrid protocols: ElGRP: reliability metric 


metrics: hop count (RIP) 
hop count 


RIP: hop count; distance-vector routing protocols: RIP: hop count 


metrics:!1GRP: enforcing consistency 
enforcing I|GRP metric consistency 


|GRP: metrics: forcing consistency 


Microsoft Windows 


Windows 95/98 


migration strategies 


IGRP to EIGRP 2nd 


MinCIR (minimum committed information rate) 


mnemonics 


memorization techniques 


modeling: versus simulating 


simulating: versus modeling 


modeling: WANs: with switch-configured routers 
WANs: modeling: with switch- configured routers 


internetworks: WANs: modeling with switch-configured routers; routers: switch- configured: WAN 


modeling 2nd 


modem-cap edit command 


commands: modem-cap edit 


modems: analog remote access configuration 
configuring: analog remote access 


remote access: analog: configuring; analog remote access: configuring; devices: modems: analog remote 


acces 2nd 3rd 4th 5th 6th 7th 8th 9th 


modems: debug commands 
configuring: modem support: debug commands 


routers: modem support:debug commands 2nd 3rd 4th 


modes of asynchronous operation 
Moy, John 
MPPC (Microsoft Point-to-Point Compression) 
MTU 
EIGRP metric 


MTU (maximum transmission unit) 


multilink command 


commands: multilink 


mutual redistribution 
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named access lists: allowing odd subnets 


configuring: named access lists: filtering even subnets 


odd subnets: filtering with named access lists; access lists: named: filtering even subnets 


named access lists: configuring 


configuring: named access lists 


access lists:named: configuring 2nd 


named access lists: example 


access lists: named: example 


naming convention 
IEEE802.3 
NAT 


debug commands 


processing 


packets from inside network 2nd 


packets from outside network 


show commands 2nd 


NAT: address pools: configuring 


address pools: configuring 


NAT: configuring 
configuring: NAT 2nd 


NAT: dynamic translation 
dynamic translation 


translation (NAT): dynamic 


NAT: dynamic translation: configuring 


configuring: NAT: dynamic translation 


dynamic translation (NAT):configuring 2nd 


NAT: Easy | P: configuring 
configuring: NAT: Easy IP 


Easy IP:configuring; PAT (Port Address Translation): configuring; TCP overload: configuring 2nd 


NAT: FTP: improper translation, debugging 


FTP: NAT translation: troubleshooting 


troubleshooting: NAT: improper FTP translation 2nd 


NAT: inside global addresses: translation 


inside global addresses: NAT translation 


NAT: inside networks: configuring 


configuring: NAT: inside networks 


NAT: Internet access: configuring 


configuring: NAT: Internet access 
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subnets: Internet access configuration 2nd 


NAT: NAT pools: configuring 
configuring: NAT: NAT pools 
NAT pools: configuring 


NAT: nonstandard FTP port numbers 
nonstandard FTP port numbers 


FTP: nonstandard port numbers: NAT translation; 


NAT: outside networks: configuring 


configuring: NAT: outside networks 


NAT: private IP addresses 
private IP addresses 


RFC 1918 AdressAllocationforPrivatel nternets 2nd 


NAT: route maps: configuring 
configuring: NAT: route maps 


route maps: configuring for NAT translation 


NAT: static translation: configuring 
configuring: NAT: static mapping 
static NAT translation: configuring; translation (NAT):static: configuring 2nd 3rd 4th 5th 6th 7th 


8th 
configuring: NAT: static translation 


static translation (NAT): configuring 


NAT: supported traffic types 
traffic: types supported by NAT 
supported traffic types: NAT 


NAT: testing configuration 


testing: NAT configuration 


NCP (Network Conrol Protocol) 
PPP: NCP (Network Control Protocol) 


NCP (Network Control Protocol) 


neighbor table: EIGRP 
EIGRP: neighbor table 


neighbors 2nd 
NetBEUI 
bridged protocols: NetBEUI 


NetBEUI:Windows 95/98 configuration 
configuring: Windows 95/98:NetBEUI 2nd 


network layer protocol phase (LCP) 


Network LSAs 


NNI (network-to-network interface) 
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NNI (Network-to-Network Interface) 
Frame Relay: NNI 
WANs: Frame Relay: NNI 


no auto-summary command 


commands: no auto-summary 


no frame-relay inverse-arp command 


commands: no frame-relay inverse-arp 


no keepalive command 


commands: no keepalive 


nonbackbone, nonstub areas 


nonroutable protocols 
SNA 

nonroutable protocols, transporting 
SRB 


operational status, displaying 2nd 


nonroutable protocols, transporting: SRB: multiport, configuring 
configuring: multiport SRB 
multiport SRB:configuring 2nd 3rd 


nonroutable protocols, transporting: SRB: remote, configuring 
configuring: remote SRB 


remote SRB:configuring 2nd 3rd 4th 


nonroutable protocols, transporting: transparent bridging: STP 


transporting nonroutable protocols:transparent bridging:STP 2nd 3rd 4th 5th 


nonstub routers 
routers: nonstub 


devices: routers: nonstub 


NSSA external LSA 


NSSA Type 1 paths (OSPF) 


NSSA type 2 paths (OSPF) 


NSSAs (not-so-stubby areas) 


NT-1 interface 
interfaces: |SDN: NT-1 
ISDN:NT-1 interface 


NT1 (Network Termination 1) 


NT2 (Network Termination 2) 


NTP 
SNTP 
NTP (Network Time Protocol) 


version 3 
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ntp authentication command 


commands: ntp authentication 


ntp clock-period command 


commands: ntp clock- period 


ntp master command 


commands: ntp master 


NTP: authentication: configuring 
configuring: NTP: authentication 


authentication: NTP configuration; security: authentication: NTP configuration 


NTP: broadcast client mode: configuring 
configuring: NTP: broadcast client mode 


broadcast client mode: NTP configuration 2nd 


NTP: clients: configuring 
configuring: NTP: clients 


clients: NTP: configuring 2nd 3rd 


NTP: configuring 
configuring: NTP 


NTP: connectivity: testing 
testing: NTP connectivity 


connectivity: NTP: testing 


NTP: daylight savings time: configuring 
configuring: NTP: daylight savings time 


daylight savings time: NTP configuration 


NTP: debug commands 


SNTP: debug commands 


NTP:1P addresses: configuring 


configuring: NTP:|P addresses 2nd 


NTP: master router: configuring 
configuring: NTP: master router 


master router:NTP configuration 2nd 


NTP: peer associations: configuring 
configuring: NTP: peer associations 


peer associations: NTP configuration 2nd 3rd 


NTP: static client mode: configuring 
configuring: NTP: static client mode 


static client mode: NTP configuration 2nd 3rd 


NTP: time zone: configuring 
configuring: NTP: time zone 


time zone: NTP configuration 
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NTP: time zones: configuring 
configuring: NTP: time zones 


time zones: NTP configuration 2nd 


Nyquist's Theorem 
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octal cable 


cabling: octal cable 


off-hook signaling 
signaling: off- hook 


OLE LINK1 


on-hook signaling 


opaque link states 
LSAs: opaque 
OSPF:LSAs: opaque; routing protocols: OSPF: opaque LSAs; link-state routing protocols: OSPF: opaque 


LSAs 2nd 
operation: of link-state routing protocols 
link-state routing protocols: operation 


routing protocols: link-state:operation 2nd 


OSPF (Open Shortest Path First) 
link-state protocols: OSPF 


routing protocols: OSPF; open routing protocols 


OSPF: adjacencies 
adjacencies: OSPF 


link-state protocols: OSPF: adjacencies; routing protocols: OSPF: adjacencies 2nd 3rd 4th 


OSPF: adjacencies: criteria 
adjacencies (OSPF): criteria 


link-state protocols: OSPF: adjacencies, criteria; routing protocols: OSPF: adjacencies, criteria 


OSPF: areas: configuring 
configuring: OSPF: areas 


areas (OSPF): establishing; establishing: OSPF areas; link-state protocols: OSPF: areas, establishing; rout 


2nd 
OSPF:BDRs (backup designated routers) 
BDRs (backup designated routers): OSPF 
link-state protocols: OSPF: BDRs; routing protocols: OSPF: BDRs; routers:BDRs 2nd 


OSPF: broadcast networks 
broadcast networks: OSPF 


link-state protocols: OSPF: broadcast networks; routing protocols: OSPF: broadcast networks 


OSPF: configuring 
configuring: OSPF 


link-state protocols: OSPF: configuring; routing protocols: OSPF: configuring 


OSPF: default routing 
default routing: OSPF 
link-state protocols: OSPF: default routing; routing protocols: OSPF: default routing 2nd 
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OSPF: default routing: lab exercises 
default routing: OSPF: lab exercises 


link-state protocols: OSPF: default routing, lab exercises; routing protocols: OSPF: default routing, lab 


2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 


OSPF: DRs (designated routers) 
DRs (designated routers): OSPF 
link-state protocols: OSPF: DRs; routing protocols: OSPF: DRs;routers:DRs 2nd 


OSPF: flooding reduction 
link-state protocols: OSPF: flooding reduction 


routing protocols: OSPF: flooding reduction; reducing: OSPF floods 


OSPF:hello protocol 
hello protocol (OSPF) 


link-state protocols: OSPF: hello protocol; routing protocols: OSPF:hello protocol 2nd 


OSPF:LSAs 
link-state protocols: OSPF: LSAs 
routing protocols: OSPF: LSAs;LSAs (OSPF) 


OSPF: multiple area routing: lab exercises 
multiple area routing (OSPF):lab exercises 


link-state protocols: OSPF: multiple area routing, lab exercises; routing protocols: OSPF: multiple area 


2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 
21st 22nd 23rd 24th 25th 
OSPF:NBMA networks 


NBMA networks: OSPF 
link-state protocols: OSPF: NBMA networks; routing protocols: OSPF: NBMA networks 


OSPF: neighbors: configuring 
configuring: OSPF: neighbors 
neighbors (OSPF): establishing; establishing: neighbors (OSPF); link-state protocols: OSPF: neighbors, 


con 2nd 
OSPF: optional parameters: configuring 
configuring: OSPF: optional parameters 


link-state protocols: OSPF: optional parameters, configuring; routing protocols: OSPF: optional 


parameter 
OSPF: over Frame Relay: configuring 
configuring: OSPF over Frame Relay 


Frame Relay: OSPF: configuring; link-state routing protocols: OSPF: configuring over Frame Relay; 


routing 2nd 
OSPF: over Frame Relay: configuring multiple area types 
WANs: Frame Relay: OSPF area configuration 


Frame Relay: OSPF: multiple area types, configuring; link-state protocols: OSPF: multiple areas, 
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configur 2nd 3rd 4th 5th 6th 7th 


OSPF: path manipulation:lab exercises 
path manipulation (OSPF):lab exercises 
link-state protocols: OSPF: path manipulation, lab exercises; routing protocols: OSPF: path 


manipulation, 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 


OSPF: path types 
link-state protocols: OSPF: path types 


routing protocols: OSPF: path types; path types:OSPF 2nd 3rd 
OSPF: point-to- multipoint networks 
point-to-multipoint networks: OSPF 


link-state protocols: OSPF: point-to-multipoint networks; routing protocols: OSPF: point-to-multipoint ne 


OSPF: point-to-point networks 
point-to-point networks: OSPF 


link-state protocols: OSPF: point-to-point networks; routing protocols: OSPF: point-to-point networks 


OSPF: redistributing into RIP 


maintaining: reachablity during redistribution 


OSPF: redistribution: example 
link-state protocols: OSPF: redistribution, example 


routing protocols: OSPF: redistribution, example 2nd 3rd 


OSPF: redistribution: lab exercises 
redistribution: OSPF: lab exercises 
link-state protocols: OSPF: redistribution, lab exercises; routing protocols: OSPF: redistribution, lab e 


2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 


OSPF:RIDs (router | Ds) 
RIDs (router |Ds) 


link-state protocols: OSPF: RIDs; routing protocols: OSPF:RIDs 2nd 


OSPF: route filtering: controlling 
controlling: OSPF route filtering/redistribution 


redistribution: OSPF: controlling; route filtering: OSPF: controlling; link-state protocols: OSPF: route fil 


2n 


a. 


OSPF: route filtering: example 
link-state protocols: OSPF: route filtering, example 


routing protocols: OSPF: route filtering, example; route filtering: OSPF: example; redistribution: OSPF: 


exa 2nd 3rd 
OSPF: route table: building 
establishing: OSPF route table 


route table: OSPF: establishing; link-state protocols: OSPF: route table establishment; routing protocols: 


2n 


Qa 


OSPF: router types 
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link-state protocols: OSPF: router types 


routing protocols: OSPF: router types 


OSPF: routing updates: controlling 
routing updates: OSPF: controlling 
controlling: OSPF routing updates; link-state protocols: OSPF: routing updates, controlling; routing prot 


2nd 


OSPF: special area types: configuring 
configuring: OSPF: special area types 


establishing: OSPF areas: special types; link-state protocols: OSPF: special area types, configuring; rout 


OSPF:stub areas: configuring 
configuring: OSPF: stub areas 


areas (OSPF):stub areas: configuring; stub areas: configuring; link-state protocols: OSPF:stub areas, 


con 
OSPF:summarization 
link-state protocols: OSPF: summarization 


routing protocols: OSPF: summarization; summarization:OSPF 2nd 3rd 


OSPF:summarization: lab exercises 
summarization: OSPF: lab exercises 
link-state protocols: OSPF: summarization, lab exercises; routing protocols: OSPF:summarization, lab 


exe 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 


OSPF: technical overview 
technical overview: OSFP 


link-state protocols: OSPF: technical overview 


OSPF: tuning 
tuning: OSPF 


performance: OSPF: tuning; link-state protocols: OSPF: tuning; routing protocols: OSPF:tuning 2nd 


OSPF: versus distance vector protocols 
link-state protocols: OSPF: versus distance vector protocols 


routing protocols: OSPF: versus distance vector protocols 2nd 


OSPF: virtual links 
virtual links: OSPF 


link-state protocols: OSPF: virtual links; routing protocols: OSPF: virtual links 2nd 3rd 


overengineered protocols 


overload command 


commands: overload 
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PAM (pulse amplitude modulation) 


PAP authentication: configuring over asynchronous interface 


authentication: PAP: configuring over asynchronous interface 2nd 


passive interfaces: defining 
defining: passive interfaces 


interfaces: passive:|SDN configuration 2nd 


passive-interface command 


commands: passive-interface 2nd 3rd 4th 


passwords: recovering: on Catalyst switches 
recovering passwords: on Catalyst switches 


authentication: passwords: recovering on Cat alyst switches; switches: password recovery; devices: 


switche 2nd 
passwords: recovering: on routers 
recovering passwords: on routers 


authentication: passwords: recovering on routers; routers: password recovery; devices: routers: password 


re 2nd 3rd 4th 5th 6th 7th 


path costs 
bridging: path costs 
STP: path costs; Ethernet: STP: path costs 


path determination 


longest match lookup 


payload compression 


PBXs:E&M signaling 


switches: PBXs: E&M signaling 2nd 
PCM 


PCM (pulse code modulation) 


phone handset 
physical-layer async command 


commands: physical-layer async 


pinouts: RJ-45 Tl loopback plugs 
loopback plugs: pinouts 


CSU/DSUs: loopback plugs: pinouts 


planning 
Cisco 1OS software upgrade 


verifying available memory 


PLAR (private line automatic ring down) 
Bat Phone configuration 


configuring: PLAR 2nd 
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PNNI (Private Network-to- Network Interface) 
ATM: PNNI 
WANs: ATM: PNNI 


poison reverse 
port speed: comparing to modem transmission rate 
modems: transmission rate: comparing to port speed 


comparing: port speed and modem transmission rate 


PPP (Point-to-Point Protocol) 


PPP multilink: configuring 


configuring: PPP multilink 


bundling; links: bundling; WANs: links: bundling 2nd 


ppp reliable-link command 


commands: ppp reliable-link 


PPP: analog backup for synchronous links, configuring 
configuring: PPP: analog backup for synchronous links 


links: synchronous: configuring PPP analog backup 2nd 3rd 4th 5th 6th 7th 8th 9th 


PPP: compression, configuring 
configuring: PPP: compression 


compression: PPP: configuring; WANs: PPP: compression, configuring 2nd 3rd 


PPP: configuring over asynchronous dialup 
configuring: PPP: over asynchronous dialup 


dialup connections: asynchronous:PPP configuration 2nd 3rd 4th 5th 6th 7th 


PPP: LCP (Link Control Protocol) 
LCP (Link Control Protocol) 
WANs: PPP: LCP 
PPP: LCP (Link Control Protocol): phases of operation 
LCP (Link Control Protocol): phases of operation 


WANs: PPP: LCP; operation: of LCP 


PPP: operation 


operation of PPP 


PPP: physical layer: testing 
testing: PPP physical layer functionality 


physical layer: PPP session functionality, testing 


PPP: RFCs 
WANs: PPP: RFCs 


PPP: show commands 
PPP: debug commands 


WANs: PPP: show commands; WANs: PPP:debug commands 2nd 3rd 


practice labs: Darth Ried 
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Darth Ried practice lab 2nd 3rd 4th 


practice labs: Darth Ried: timed portion 
Darth Ried practice lab: timed portion 


timed portion: Darth Ried practice lab 2nd 3rd 4th 5th 


practice labs: Skynet 
Skynet practice lab 2nd 


practice labs: Skynet: prestaging 
Skynet practice lab: prestaging 
prestaging: Skynet practice lab 2nd 3rd 


practice labs: The Enchilada 


The Enchilada practice lab 


practice labs: The Enchilada: prestaging 
The Enchilada practice lab: prestaging 
prestaging: The Enchilada practice lab 


practice labs: The Enchilada: timed portion 
The Enchilada practice lab: timed portion 


timed portion: The Enchilada practice lab 2nd 3rd 4th 5th 


practice labs: The Lab, The Bad, The Ugly: prestaging 
prestaging: The Lab, The Bad, The Ugly practice lab 2nd 


practice labs: The Lab, The Bad, The Ugly: timed portion 
timed portion: The Lab, The Bad, The Ugly practice lab 2nd 3rd 4th 5th 


practice labs: The Unnamed Lab 


The Unnamed Lab practice lab 


practice labs: The Unnamed Lab: prestaging 
The Unnamed Lab practice lab: prestaging 


prestaging: The Unnamed Lab practice lab 2nd 3rd 


practice labs: The Unnamed Lab: timed portion 
The Unnamed Lab practice lab: timed portion 


timed portion: The Unnamed Lab practice lab 2nd 3rd 4th 5th 


predictor compression 


preparing for CCIE one-day exam: recommended resources 


study preparation, CCIE one-day exam: recommended resources 2nd 


preparing for CCIE one-day exam: timed portion 
study preparation, CCIE one-day exam: timed portion 


timed portion: CCIE certification 2nd 3rd 4th 5th 


PRI (Primary Rate Interface) 
ISDN:PRI 
WANs:!ISDN: PRI 


primary interfaces (HSRP): configuring 
1259 


secondary interfaces (HSRP):configuring 2nd 3rd 


priority command 


commands: priority 


promiscuous peers 


DLSw+ configuration 2nd 


PVCs 


Classical |P implementation 2nd 


Frame Relay: PVCs 
WANs: Frame Relay: PVCs 


PVCs (permanent virtual circuits) 


PVCs-based ATM networks, implementing 


PVCs-based ATM networks, implementing: dynamic PVCs 
dynamic PVCs:RFC 2468 implementation 2nd 


PVCs-based ATM networks, implementing: static PVCs 
static PVCs: RFC 2468 implementation 2nd 3rd 


PVCs: Classical IP implementation 
|InATMARP 
PVST (Per VLAN Spanning Tree) 
STP: PVST 
Ethernet: STP: PVST 
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q933a LMI 
Q933a LMIs 


LMIs:Q933a 
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R reference point 


receive control switch (RIP-2) 


redistribution command 


commands:redistribution 


reference points 
ISDN: reference points 


WANs: ISDN: reference points 


reliability 
as metric 
IGRP metric 
remote access 
DDR 


advanced DDR with dialer profiles 


legacy DDR 
remote SRB: encapsulation types 
SRB: remote: encapsulation types 


encapsulation types: SRB 


requirements: available memory: verifying 
verifying: available memory for |OS upgrade 


upgrading: Cisco |OS software: verifying available memory; Cisco |OS software: upgrading: verifying 


avail 


resign message (HSRP) 


response messages (RIP) 
RIP: response messages 


RIP: receive messages; messages: RIP; distance-vector routing protocol: RIP: messages; routing 


protocols: di 


reverse Telnet 


router configuration 


reverse Telnet sessions: absolute line number: clearing 


absolute line number: clearing 


reverse Telnet sessions: connecting to all routers in model 


configuring: reverse Telnet sessions: connecting to all routers in model 


reverse Telnet sessions: opening 
opening: reverse Telnet sessions 


RFC 1661 


RFC 2684: configuring: lab exercises 
lab exercises: RFC 2684 configuration 


configuring: RFC 2684:lab exercises; ATM: RFC 2684 configuration: lab exercises; WANs: ATM: RFC 2684 


2nd 3rd 4th 5th 6th 7th 


RIF (routing informtion field) 
SRB: RIF 
bridging: SRB: RIF 


ring lists (DLSw+): configuring 
bridge group lists (DLSw+): configuring 
port lists (DLSw+):configuring 2nd 3rd 


ringer 

ringing 

RIP-2: backwards compatibility with RIP-1 
backward compatibility: of RIP-2 


RIP: configuring 
configuring: RIP-1 


distance-vector routing protocols: RIP: configuring; routing protocols: RIP: configuring 


configuring: RI P-2 


distance-vector routing protocols: RIP: configuring; routing protocols: RIP: configuring 2nd 


RIP: default routing 
default routing: RIP 
distance-vector routing protocols: RIP: default routing; routing protocols: RIP: default routing; configur 


2nd 


RIP: initialization 
distance-vector routing protocols: RIP: initialization 


routing protocols: distance vector: RIP; initialization: RIP 


RIP: multipoint subinterfaces, configuring 
configuring: RIP: multipoint subinterfaces 


multipoint subinterfaces: configuring 2nd 


RIP: routing updates 
routing updates: RIP 


distance-vector routing protocols: RIP: routing updates; routing protocols: distance-vector: RIP; 


updates: 
RIP: summarization 
summarization: RIP 


distance-vector routing protocols: RIP:summarization; routing protocols: RIP: summarization 


RIP: timers 
timers: RIP 

RJ-45 adapter pinouts 
pinouts: R]-45 adapters 


RJ -45 ports 


Cisco 2511 access server 
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robbed-bit signaling 


ROM monitor mode 
indicators 

ROM monitor mode (Cisco 1OS software): entering 
Cisco |OS Software: ROM monitor mode: entering 


break key combinations; key combinations: interrupting switch/router operations; interrupting: switch/ 


ro 2nd 
ROM monitor mode: commands 


commands:ROM monitor mode 2nd 


root bridges 


STP: root bridges 


routable protocols: forwarding 
forwarding: routable protocols 


packets: path determination; path determination; routing protocols: path determination 2nd 


route generators: configuring 
configuring: route generators 


devices: route generators: configuring 2nd 3rd 4th 5th 


route generators: pinging 


devices: route generators: pinging 2nd 


route generators: tracing 


devices: route generators:tracing 2nd 


route invalidation timers 


timers: route invalidation timers 2nd 


route table 2nd 


route table: EIGRP 
EIGRP: route table 
forwarding table: EIGRP 


Router LSAs 


router on a stick 


router rip command 


commands: router rip 


router-id command 


commands: router-id 


RouterDeadl nterval (OSPF) 
OSPF: RouterDeadI nterval 


link-state protocols: OSPF: RouterDeadInterval; routing protocols: OSPF: RouterDeadI nterval 


routers: AUX port: modem configuration 
AUX ports: modem configuration 


configuring: AUX ports for modem hookup 
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routers: modem support: configuring 


devices: routers: modem support, configuring 2nd 3rd 


routing protocols 


OSPF 


multiple areas, configuring over Frame Relay 2nd 3rd 4th 5th 6th 7th 


RIP 
initialization 
messages 


routing updates 


routing algorithm 


routing protocols: classless 


classless routing protocols 


routing protocols: distance vector 
distance vector routing protocols 


Bellman-Ford algorithms 


routing protocols: distance vector: characteristics 
distance vector routing protocols: characteristics 


characteristics: of distance vector routing protocols 2nd 


routing protocols: distance vector: operation 
distance vector routing protocols: operation 


operation: of distance vector routing protocols 


routing protocols: filtering 


filtering: routing protocols 


routing protocols: 1GRP 
distance vector protocols:!GRP 


IGRP (Interior Gateway Routing Protocol) 


routing protocols: link state: comparing to distance vector 


comparing: link-state and distance vector routing protocols 


distance vector routing protocols: versus link-state;link-state routing protocols: versus distance vec 


routing protocols: metrics 
metrics 


path determination: metrics 2nd 


routing updates 


|GRP 
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S reference point 
T reference point 


U_ reference point 


scalability 
IGRP 

security: authentication: OSPF 
OSPF: authentication 


link-state protocols: OSPF: authentication; routing protocols: OSPF: authentication; authentication: OSPF 


OSPF: authentication: Type 1 


link-state protocols: OSPF: authentication; routing protocols: OSPF: authentication; authentication: OSPF: 


I 2nd 3rd 
OSPF: authentication: Type 2 


link-state protocols: OSPF: authentication; routing protocols: OSPF: authentication; authentication: OSPF: 


T 2nd 
sending 


break signal to router/switch 2nd 3rd 


Abort at message 2nd 


serial interfaces: PPP configuration 
configuring: PPP: on serial interfaces 


PPP: serial interface configuration 2nd 


serial interfaces: tracking 


tracking: on serial interfaces 


server mode (VTP) 
client mode (VTP) 
transparent mode (VTP) 


set enablepass command 


commands: set enablepass 


set spantree portvlancost command 


commands: set spantree portvlancost 


set spantree portvlanpri command 


commands: set spantree portvlanpri 


set spantree priority command 


commands: set spantree priority 


set spantree root command 


commands: set spantree root 


show access-list command 


commands: show access-list 2nd 


show bridge command 
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commands: show bridge 


transparent bridging: operational status: displaying; displaying: transparent bridging operational statu 


show clock command 


commands: show clock 


show commands:HSRP 
HSRP: show commands 


HSRP: debug commands; debug commands: HSRP 


show controller command 


commands: show controller 


show controllers command 


commands: show controllers 


show dialer command 


commands:show dialer 2nd 


show dlsw capabilities command 


commands: show dlsw capabilities 


show dlsw circuits command 


commands: show dlsw circuits 


show disw peer command 


commands: show disw peer 2nd 


show dlisw peers command 


commands: show disw peers 2nd 


show dlsw reachability command 


commands: show dlsw reachability 2nd 3rd 


show eigrp neighbors command 


commands: show eigrp neighbors 2nd 


verifying: EIGRP operational status 2nd 3rd 


show flash command 


commands: show flash 


show frame-relay command: evaluating output 
evaluating: show frame-relay command output 


output: show frame-relay command:evaluating 2nd 


show frame-relay Imi command 


commands: show frame-relay Imi 


LMI: statistics, displaying; displaying: Frame Relay LMI statistics; Frame Relay: LMI: statistics, display 
2nd 


show frame-relay map command 


commands: show frame-relay map 


show frame-relay pvc command 


commands: show frame-relay pvc 
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Frame Relay:PVCs: statistics, displaying; displaying: Frame Relay PVC statistics; PVCs: statistics, displ 
2nd 3rd 


show frame-relay route command 


commands: show frame-relay route 


show interface bri 0 command 


commands: show interface bri 0 


show interface command 


commands:show interface 2nd 3rd 4th 5th 


show interface serial command 


commands: show interface serial 


show ip access-list command 


commands: show ip access-list 2nd 


show ip eigrp topology command 


commands: show ip eigrp 2nd 3rd 


show ip nat statistics command 


commands: show ip nat statistics 


show ip nat translations command 


commands: show ip nat translations 2nd 


show ip nat translations verbose command 


commands: show ip nat translations 


show ip ospf command 


commands: show ip ospf 


show ip ospf database command 


commands: show ip ospf database 2nd 


show ip ospf interface command 


commands: show ip ospf interface 


show ip ospf neighbor command 


commands: show ip ospf neighbor 


show ip ospf neighbors command 


commands: show ip ospf neighbors 2nd 3rd 


show ip protocols command 


commands: show ip protocols 2nd 3rd 


show ip route command 


commands: show ip route 2nd 3rd 4th 5th 6th 


|GRP: routing table: displaying; displaying:|GRP routing table; distance vector protocols:|GRP: routing t 


trace command; commands: trace 


trace command; commands; trace 


show isdn active command 


commands: show isdn active 
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show isdn status command 


commands: show isdn status 2nd 3rd 


show line command 


commands:show line 2nd 3rd 


show line command: performing on access servers 
access servers: show line command output 


commands: show line: performing on access servers 2nd 


show log command 


commands: show log 2nd 


show ntp associations command 


commands: show npt associations 


commands: show ntp associations 2nd 3rd 


show ntp status command 


commands: show ntp status 2nd 


show ospf neighbor command 


commands: show ospf neighbor 


show processes command 


commands: show processes 2nd 


show sntp command 


commands: show sntp 2nd 


show spanning-tree command 


commands: show spanning-tree 


show standby command 


commands: show standby 


show standby ethernet command 


commands: show standby ethernet 


show standby interface command 


commands: show standby interface 


show version command 


commands:show version 2nd 


sidetone 
signaling: address signaling 
address signaling 


analog telephony: signaling: address signaling; pulse address signaling; make segment (pulse 


signaling); 
signaling: trunk/line seizure: E&M 
trunks: E&M signaling 
analog telephony: trunks: E&M signaling; E&M signaling 2nd 


signaling: trunk/line seizure: ground start 
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trunks: ground start signaling 


analog telephony:trunks: ground start signaling; ground start signaling 2nd 


signaling: trunk/line seizure: loop start 
trunks: loop start signaling 


analog telephony:trunks:loop start signaling; loop start signaling 


SIMMs: available Flash space: viewing 
Flash memory: available memory: displaying 


memory: Flash: available memory, displaying 


simulating: WAN connections 
internet: WAN connections: simulating 


WAN connections: simulating; modeling: WANs 


simulating: WANs: with loopback plugs on CSU/DSUs 
WANs: simulating: with loopback plugs on CSU/DSUs 
internetworks: WANs: simulating with loopback plugs on CSU/DSUs; CSU/DSUs: loopback plugs: WAN 


simulation 2nd 3rd 


SLARP (Serial Line ARP) 


SLIP (Serial Line Internet Protocol) 


snapshot quiet time 


snapshot routing 
interfaces: snapshot routing 


spoofing: snapshot routing 


ISDN:DDR: snapshot routing 
DDR: snapshot routing; configuring: DDR: snapshot routing 2nd 3rd 4th 5th 


SNTP (Simple Network Time Protocol) 


sntp broadcast client command 


commands: sntp broadcast client 


SNTP: configuring 
configuring: SNTP 2nd 


SNTP:show command 


NTP:show commands 2nd 


show ntp status command; commands: show ntp status 


Software Center: selecting Cisco |OS software 


selecting: Cisco |OS software 


solutions to lab exercises: URL 


lab exercises: solutions to: web site 


source algorithms 


SPF (Shortest Path Tree) 
OSPF:SPF tree 
link-state protocols: OSPF: SPF tree; routing protocols: OSPF: SPF tree; cost metric (OSPF); OSPF: cost 


1270 


metr 2nd 


SPF tree 
SPI Ds (service profile identifiers) 
ISDN:SPID values 
WANs:!ISDN: SPID values 


split horizon 
interfaces: split horizon 


subinterfaces: split horizon 


split horizon: ElGRP 
EIGRP: split horizon 


hybrid protocols: EIGRP: split horizon; routing protocols:EIGRP: split horizon 2nd 


SRB: largest frame size, setting 
bridging: SRB: largest frame size, setting 


transporting nonroutable protocols: SRB: setting largest frame size; nonroutable protocols, transportin 


SRB: static RIF: configuring 
configuring: SRB: static RIF 
static RIF: SRB configuration; bridging: SRB: static RIF configuration; RIF (SRB):static configuration 
2nd 3rd 4th 


SRB: STP: explorer configuration 
bridging: SRB: STP explorer configuration 


transporting nonroutable protocols:SRB:STP explorer configuration; nonroutable protocols, 


transportin 


STAC compression algorithm 
compression: STAC 


Lempel-Ziv compression algorithm; compression: Lempel-Ziv 


Stacker compression 


standard access lists: implicit deny 


access lists: standard: implicit deny 


standby priority 


static mapping: Frame Relay configuration 
configuring: Frame Relay: static mapping 


Frame Relay:static mapping configuration 2nd 


static routes 


floating 


store-and-forward switching 


STP: assigning bridge group number 
assigning: bridge group number to STP 


bridge group number: assigning to STP 


STP: disabled state 
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disabled state (STP) 
transparent bridging: STP: disabled state; bridging: transparent: STP; Ethernet: transparent bridging: STP 


STP: forwarding state 
forwarding state (STP) 
transparent bridging: STP: forwarding state; bridging: transparent: STP; Ethernet: transparent bridging: 


STP 2nd 
STP: learning state 
learning state (STP) 
transparent bridging: STP: learning state; bridging: transparent: STP; Ethernet: transparent bridging: STP 


STP: listening state 
listening state (STP) 


transparent bridging: STP:listening state; bridging: transparent: STP; Ethernet: transparent bridging: STP 


2nd 
STP: timers 
Ethernet: STP: timers 
timers: STP;|EEE 802.1d (STP):timers;loop prevention: STP: timers 


timers: STP 


transparent bridging: STP: timers; bridging: transparent: STP; Ethernet: transparent bridging: STP 


stub routers: configuring 
configuring: stub routers 


OSPF:stub routers: configuring 


sub areas 
subinterfaces: Frame Relay encapsulation type, configuring 
interfaces: Frame Relay: configuring encapsulation type 


encapsulation: Frame Relay interfaces: configuring; Frame Relay: encapsulation type, configuring 


sublayers: of data link layer 
data link layer: sublayers 


OSI reference model: data link layer: sublayers 


Subnet 0 rule 
NAT: Subnet 0 rule 
limitations: of NAT: Subnet 0 rule 


subnet routes (1GRP) 


Summary LSAs 


supervisory signaling 
off-hook 2nd 
ringing 
suspending a session 
reverse Telnet sessions: suspending 


Telnet sessions: suspending; re-establishing Telnet connections; relative line numbers; show session 
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com 


SVC-based ATM networks, implementing 2nd 3rd 


SVCs 


Classical |P implementation 2nd 3rd 


switch hook 
switched Ethernet: broadcast domains 
IEEE 802.3:switched Ethernet: broadcast domains 


Ethernet: switched: broadcast domains; Ethernet: switched: collision domains; switched Ethernet: collision 


switched Ethernet: Catalyst switches: configuring 
configuring: Catalyst Ethernet switches 
Ethernet: switched: configuring Catalyst switches; Catalyst switches: switched Ethernet: configuring; 
IEEE 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 
20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th 30th 31st 32nd 33rd 34th 35th 36th 37th 
38th 39th 40th 41st 42nd 43rd 44th 45th 46th 47th 48th 


switched Ethernet: lab exercises 
lab exercises: switched Ethernet 
VLAN trunking: lab exercises; lab exercises: VLAN trunking; STP: root placement: lab exercises; lab 


exercis 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 


switched Ethernet: trunking protocols 
trunking protocols 


[EEE 802.3:switched Ethernet: trunking protocols; Ethernet: switched: trunking protocols 2nd 3rd 4th 


5th 
switched Ethernet: trunking protocols: DISL 
trunking protocols: DISL 
[EEE 802.3:switched Ethernet: trunking protocols; Ethernet: switched: trunking protocols; DISL 


(Dynamic | 
switched Ethernet: trunking protocols: DTP 


trunking protocols: DTP 
IEEE 802.3:switched Ethernet:trunking protocols; Ethernet: switched: trunking protocols; DTP (Dynamic 


Ir 
switched Ethernet: VTP 
VTP (VLAN Trunking Protocol) 


IEEE 802.3:switched Ethernet: VTP; Ethernet:switched: VTP 2nd 3rd 4th 


switching: Frame Relay: commands 
Frame Relay: switching: commands 


configuring: Frame Relay switching:commands; 2nd 3rd 4th 


switching:!1SDN protocols 
signaling:|SDN protocols 
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switching: Token Ring:lab exercises 
lab exercises: Token Ring switching 


Token Ring:switching:lab exercises 2nd 3rd 4th 5th 


syntax: extended IP access lists 
extended IP access lists: syntax 


access lists: extended | P: syntax 


system routes (IGRP) 
network routes (IGRP) 
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TA (Terminal Adapter) 


TCN (Topology Change Notification) BPDUs 


TCP encapsulation (SRB) 
configuring 

TCP header compression 
compression: payload compression 


payload compression 


compression: TCP header compression 


TE1 (Terminal Equipment Type 1) 
TE2 (Terminal Equipment Type 2) 


terminal server cables 


access server cabling options 


testing: access server configuration 
access servers: testing configuration 


devices: access servers:testing configuration 2nd 


testing: dynamic access list configuring 


dynamic access lists: testing configuration 


testing: Frame Relay switch configuration 


Frame Relay: switching:testing configuration 2nd 


testing: HSRP configuration 
HSRP: testing configuration 
default gateway: HSRP: testing configuration 2nd 


testing: NAT configurations 


NAT: testing configuration 


third-party routers 
routers: third-party 


devices: routers: third-party 


Thomas, tom 


timers 
OSPF 
tuning 
timers basic command 


commands: timers: basic 


timers: adjusting 


adjusting: RIP timers 


timers: for dynamic access lists: configuring 


dynamic access lists: timers: configuring 2nd 3rd 


timers:| GRP: tuning 
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|GRP: timers: tuning 


tip and ring 
Token Ring: switching 
switching: Token Ring 
IEEE 802.5: switching; TXI (transmit immediate) 


Token Ring: switching: Catalyst 3920 configuration 
switching: Token Ring: Catalyst 3920 configuration 
configuring: Token Ring switching: on Catalyst 3920; Catalyst 3920:Token Ring switching: configuring 
2nd 3rd 4th 5th 6th 7th 8th 9th 
topology table: ElIGRP 


EI GRP: topology table 


TOS (type-of-service) values 


extended IP access lists 


totally stubby areas 


trace command 


commands: trace 


traffic: access lists: applying in bridged environments 


bridging: access lists: applying in bridged environments 2nd 


traffic: access lists: filtering NetBIOS names addresses 


bridging: access lists: filtering MAC addresses 


traffic: load: as metric 
load: as metric 
transparent bridging: lab exercises 
lab exercises: transparent bridging 
RSRB: lab exercises; lab exercises: RSRB; LSAP filtering: lab exercises; lab exercises: LSAP filtering 2nd 


3rd 4th 5th 6th 7th 8th 9th 10th 


transport input all command 


commands: transport input all 


transporting nonroutable protocols: applying access lists in bridged environment 
nonroutable protocols, transporting: applying access lists in bridged environments 


access lists:applying in bridged environments 2nd 


transporting nonroutable protocols: DLSw: advanced configuration 
advanced configuration 
configuring: DLSw+: advanced options; nonroutable protocols, transporting: DLSw+: advanced 


configuration; 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 


transporting nonroutable protocols: filtering MAC addresses 
nonroutable protocols, transporting: filtering MAC addresses 


access lists: filtering MAC addresses; traffic: access lists: filtering MAC addresses; bridging: access li 


transporting nonroutable protocols: filtering NetBIOS names addresses 
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nonroutable protocols, transporting: filtering NetBIOS names addresses 


access lists: filtering NetBIOS names addresses 
transporting nonroutable protocols: filtering SAPs 
nonroutable protocols, transporting: filtering SAPs 


access lists: filtering SAPs; traffic: access lists: filtering SAPs; bridging: access lists: filtering SAPs 2nd 


3rd 
transporting nonroutable protocols: SRB 
SRB (source-route bridging) 
bridging: SRB; nonroutable protocols, transporting: SRB 2nd 


transporting nonroutable protocols: SRB: configuring 
SRB (source-route bridging): configuring 


bridging: SRB: configuring; nonroutable protocols, transporting: SRB: configuring; configuring: SRB 2nd 


transporting nonroutable protocols:SRB: multiport, configuring 
SRB (source-route bridging): multiport: configuring 


bridging: SRB: multiport, configuring 2nd 3rd 


transporting nonroutable protocols: SRB: operational status, viewing 
SRB (source-route bridging): operational status, displaying 


bridging: SRB: operational status, displaying; displaying: SRB operational status 2nd 


transporting nonroutable protocols: SRB: remote, configuring 
SRB (source-route bridging): remote: configuring 


bridging: SRB:remote, configuring 2nd 3rd 4th 


transporting nonroutable protocols: SRB: RIF field 
SRB (source-route bridging):RIF field 
bridging: SRB:RIF field; nonroutable protocols, transporting: SRB: RIF field; RIF field (SRB) 2nd 3rd 


transporting nonroutable protocols:SRB:RSRB TCP LLC2 local ack 
nonroutable protocols, transporting: SRB: RSRB TCP LLC2 local ack 
SRB: RSRB: TCP LLC2 local ack; RSRB: TCP LLC2 local ack; TCP LLC2 local ack (RSRB); local 


acknowledgment:T 


transporting nonroutable protocols: SRB: static RIF configuration 


nonroutable protocols, transporting: SRB: static RIF configuration 2nd 3rd 4th 


transporting nonroutable protocols: transparent bridging 
bridging: transparent 


nonroutable protocols, transporting: transparent bridging; transparent bridging; Ethernet: transparent b 


2nd 
TrBRF (Token Ring bridge relay function) 
bridging: TrBRF 
TrCRF (Token Ring concentrator relay functions); IEEE 802.5:TrBRF;|EEE 802.5:TrCRF 2nd 3rd 4th 


troubleshooting 


Frame Relay 
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evaluating debug frame-relay command output 2nd 3rd 4th 


evaluating show frame-relay command output 2nd 


troubleshooting: HDLC links: physical layer 
links: HDLC: physical layer, troubleshooting 2nd 3rd 


troubleshooting: modems: debug commands 


devices: modems:troubleshooting 2nd 3rd 4th 


troubleshooting: PPP: debug commands 


PPP: troubleshooting: debug commands 2nd 3rd 


troubleshooting: RIP:debug commands 
RIP: debug ip rip command 


distance-vector routing protocols: RIP: debug ip rip commands; routing protocols: RIP: debug ip rip 


comma 
troubleshooting: RIP: show commands 
RIP: show commands 


distance-vector routing protocols: RIP:show commands; routing protocols: RIP:show commands 2nd 


trunks 


switches: trunks 


Twinkie Theory 
bandwidth: Twinkie Theory 
Ethernet: bandwidth: Twinkie theory 


two-to-four-wire converter 


Type | E&M signaling 


Type Il E&M signaling 2nd 


Type Ill E&M signaling 


Type IV E&M signaling 


Type V E&M signaling 
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U interface (ISDN) 
CO:ISDN U interface 
switches: CO:I1SDN U interface 


unequal-cost load balancing 
IGRP 

update timer (IGRP) 
GRP: update timer 


updated Cisco 1|OS commands 
comparing: old and new Cisco |OS commands 


commands: comparing old and new; Cisco |OS software: commmands: comparing old and new 


updates 
RIP 


receive control switch 
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V.35 back-to-back connections: PPP, configuring on serial interface 


back-to-back connections: V.35: configuring PPP on serial interface 2nd 


V.35 patch panels 
patch panels: V.35 


V.35 serial cable: pinouts 


pinouts: V.35 serial cable 


variance 


IGRP, configuring 2nd 


variance command 


commands: variance 


vbr-rt command: parameters 
commands: vbr-rt: parameters 


parameters: vbr-rt_ command 


verifying 


HDLC DCE-to-DTE connectivity 


verifying: Frame Relay operation 
Frame Relay: verifying operation 


WANs: Frame Relay: verifying operation 


verifying: FRTS configuration 
FRTS: verifying configuration 
traffic: FRTS: verifying configuration 2nd 


verifying: HSRP operation 
HSRP: verifying operation of 


verifying:|GRP router connectivity 


GRP: router connectivity: verifying 


verifying: PPP multilink functionality 


PPP multilink: verifying functionality of 


verifying: routers with CONFREG utility support 
routers: CONFREG utility: verifying support for 
CONFREG utility: verifying router support; utilities: CONFREG: verifying router support; Cisco routers: CO 


2nd 
verifying: transparent bridging 
transparent bridging: verifying 


bridging: transparent: verifying; transporting nonroutable protocols: transparent bridging: verifying ope 


2nd 
viewing: startup configuration 
startup configuration: viewing 


displaying: startup configuration; Enable mode: entering; entering: Enable made; copying: startup. cantlg 


to 
virtual bridges 
VLAN pruning 
VLANs 
Ethernet: switched: VLANs 
switched Ethernet: VLANs;|EEE 802.3:switched Ethernet: VLANs; broadcast domains: VLANs 2nd 


MST 


VoATM: configuring 
configuring: VoATM 2nd 


VoATM:ILMI connectivity 
ILMI connectivity: VoATM 2nd 


vocoders 
VoFR: fragmentation: enabling 
enabling: VoFR fragmentation 


fragmentation: VoFR: enabling 


VoFR: map class definition 


configuring: VoFR: map class definition 


VoFR: voice ports: configuring 
configuring: VoFR: voice ports 


voice ports: VoFR configuration 


voice compression 
waveform 
Voice Network Modules 


Cisco routers: Voice Network Modules 


voice switches 
voice-capable routers: comparing 
comparing: Cisco voice-capable routers 


routers: Cisco voice- capable: comparing 


VoIP: configuring 


configuring: Vol P 


VTP: modes of operation 


switched Ethernet: VTP: modes of operation 
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WANs: HDLC 
HDLC (High-Level Data Link Control) 


WANs: HDLC: keepalives 
HDLC (High-Level Data Link Control): keepalives 


keepalives: HDLC 


WANs:ISDN: development 
ISDN: development 


development: of ISDN; CCITT (International Telephone and Telegraph Consultative Committee); 1TU 


(Intern 
WANs:!ISDN: interfaces 


ISDN: interfaces 


interfaces:|ISDN 2nd 


waveform algorithms 


waveform coders 


waveform compression 
ADPCM 
web sites: FRF 


FRF (Frame Relay Forum): web site 


weighted fair queuing: VoFR configuration 


configuring: VoFR: weighted fair queuing 


weighted routes 


floating static routes 


wildcard masks 
access lists: wildcard masks 


standard access lists: wildcard masks 


Windows NT:break key combination 
Catalyst switches: break key combinations 


switches: Catalyst: break key combination 


wink start signaling 
analog telephony: trunks: supervory signaling: wink start 


trunks: supervisory signaling: wink start; tie trunks: supervisory signaling: wink start; supervisory sig 
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X.21 serial cable: pinouts 


pinouts: X.21 serial cable 
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